DOMAINs and CASTs

Hi,

If i create a DOMAIN an then want to create a CAST from that domain to
another type it gives an error.
Consider this example:
"""
create domain datetime as timestamp with time zone
check (value between '1753-01-01 00:00:00' and '9999-12-31 23:59:59');

create function datetime2int(datetime) returns int
language sql stable strict as $$
select $1::date - '1753-01-01'::date;
$$;

create cast(datetime as int) with function datetime2int(datetime);
"""

if i try to cast, get this error:
select now()::datetime::int;
ERROR: cannot cast type datetime to integer

The problem is that in find_coercion_pathway() the very first thing we
do is to get the base type of both: the source and target types. So,
the way to make it work is to create the function and the cast on the
base types.
But what if i create 2 domains on the same base types and want a
different behaviour on a cast to the same target type?

ok, sounds odd... basic example datetime and smalldatetime types in ms
sql server... when casting to int the former give the number of days
since 1753-01-01 and the latter the number of days since 1900-01-01...
some systems i have seen (specially ERPs) tend to store dates as
number of days so there is a use case for this.

the fix for this doesn't look complicated (unless have missed
something), just try first with the types i receive and then with the
base types if they are domains... i'm not trying mixed situations: the
base type of the source and the target as we receive it and viceversa,
i think that's just complicating for a very little benefit if any...

attached (pass all regression tests), comments?

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL

Jaime Casanova <jaime(at)2ndquadrant(dot)com> writes:
> If i create a DOMAIN an then want to create a CAST from that domain to
> another type it gives an error.

Yes. See previous discussions about that, e.g. these threads:

http://archives.postgresql.org/pgsql-hackers/2006-05/msg00072.php
http://archives.postgresql.org/pgsql-hackers/2006-09/msg00695.php

It's *not* trivial to fix, at least not in a way that gives desirable
behavior for more than the simplest cases.

regards, tom lane

On Sat, May 14, 2011 at 5:13 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jaime Casanova <jaime(at)2ndquadrant(dot)com> writes:
>> If i create a DOMAIN an then want to create a CAST from that domain to
>> another type it gives an error.
>
> It's *not* trivial to fix, at least not in a way that gives desirable
> behavior for more than the simplest cases.
>

well, i'm just trying to manage the simplest case... do you think we
should manage other cases? what else should we do?
it's better to allows the creation of casts that are ignored?

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL

Jaime Casanova wrote:
> If i create a DOMAIN an then want to create a CAST from that domain to
> another type it gives an error.
> Consider this example:
> """
> create domain datetime as timestamp with time zone
> check (value between '1753-01-01 00:00:00' and '9999-12-31 23:59:59');
>
> create function datetime2int(datetime) returns int
> language sql stable strict as $$
> select $1::date - '1753-01-01'::date;
> $$;
>
> create cast(datetime as int) with function datetime2int(datetime);
> """
>
> if i try to cast, get this error:
> select now()::datetime::int;
> ERROR: cannot cast type datetime to integer
>
> The problem is that in find_coercion_pathway() the very first thing we
> do is to get the base type of both: the source and target types. So,
> the way to make it work is to create the function and the cast on the
> base types.
> But what if i create 2 domains on the same base types and want a
> different behaviour on a cast to the same target type?

I think that overloading the same cast syntax to get different behavior for
different domains over the same base type is a bad idea.

First of all, what if "cast(timestamp as int)" was already defined? Which cast
then would you expect to be invoked here?

'1800-01-01 00:00:00'::int

... the one for timestamp or the one for datetime?

Second of all, what if you had 2 domains defined over timestamp and they
overlapped and they both defined a cast as you did, with generic syntax? And
you were casting a value in both domains as an int?

I think it would be best that the generic cast syntax only be useable for casts
defined on the base type, and if you want a domain-specific one you should use
the function syntax such as your datetime2int().

That way it is easier for users to predict what behavior will occur, and
implementation will be easier too.

-- Darren Duncan

Darren Duncan wrote:
> I think it would be best that the generic cast syntax only be useable
> for casts defined on the base type, and if you want a domain-specific
> one you should use the function syntax such as your datetime2int().
>
> That way it is easier for users to predict what behavior will occur, and
> implementation will be easier too.

Replying to myself, I offer another alternative:

What you ask for is indeed supported, but that if for a given input value more
than one cast applies to it, particularly for 2 overlapping domains, then which
cast is invoked is undefined, so for example the DBMS may just use the first one
it finds.

It is then up to the user to ensure that when they define casts over domains
that they just define ones that either produce the same outputs for the same
overlapping inputs (the best answer) or they ensure that they don't overlap in
their input domains.

-- Darren Duncan

----- Original Message -----
From: "Darren Duncan" <darren(at)darrenduncan(dot)net>
To: "Jaime Casanova" <jaime(at)2ndquadrant(dot)com>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Sent: Saturday, May 14, 2011 9:46 PM
Subject: Re: [HACKERS] DOMAINs and CASTs

> Darren Duncan wrote:
>> I think it would be best that the generic cast syntax only be useable for
>> casts defined on the base type, and if you want a domain-specific one you
>> should use the function syntax such as your datetime2int().
>>
>> That way it is easier for users to predict what behavior will occur, and
>> implementation will be easier too.
>
> Replying to myself, I offer another alternative:
>
> What you ask for is indeed supported, but that if for a given input value
> more than one cast applies to it, particularly for 2 overlapping domains,
> then which cast is invoked is undefined, so for example the DBMS may just
> use the first one it finds.
>
> It is then up to the user to ensure that when they define casts over
> domains that they just define ones that either produce the same outputs
> for the same overlapping inputs (the best answer) or they ensure that they
> don't overlap in their input domains.
>
> -- Darren Duncan
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

On Sat, May 14, 2011 at 8:42 PM, Darren Duncan <darren(at)darrenduncan(dot)net> wrote:
>
> First of all, what if "cast(timestamp as int)" was already defined?  Which
> cast then would you expect to be invoked here?
>
>  '1800-01-01 00:00:00'::int
>

i will expect an error in that case... what you're doing there is
casting an "unknown" to integer, for that to be valid you need an
intermediate cast to timestamp or in my case to datetime

> ... the one for timestamp or the one for datetime?
>

the one of the type i cast before cast to int; for example, "select
'1800-01-01 00:00:00'::timestamp with time zone::int" i expect the
cast of timestamp with time zone to int and in "select '1800-01-01
00:00:00'::datetime::int" the for datetime to int

> Second of all, what if you had 2 domains defined over timestamp and they
> overlapped and they both defined a cast as you did, with generic syntax?
>  And you were casting a value in both domains as an int?
>

i'm not following you, currently i only can define one cast (base type
of the domain to base type of target), but if i can create casts on
domains (and they worked) i can create different behaviours just
creating different functions for every domain and an specific cast for
that domain

> I think it would be best that the generic cast syntax only be useable for
> casts defined on the base type, and if you want a domain-specific one you
> should use the function syntax such as your datetime2int().
>
> That way it is easier for users to predict what behavior will occur, and
> implementation will be easier too.
>

really? how getting an error when i already have a cast on the domain
is predictable?

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL

Jaime Casanova wrote:
> On Sat, May 14, 2011 at 8:42 PM, Darren Duncan <darren(at)darrenduncan(dot)net> wrote:
>> First of all, what if "cast(timestamp as int)" was already defined? Which
>> cast then would you expect to be invoked here?
>>
>> '1800-01-01 00:00:00'::int
>
> i will expect an error in that case... what you're doing there is
> casting an "unknown" to integer, for that to be valid you need an
> intermediate cast to timestamp or in my case to datetime

Sorry, my bad; I meant to say (might be slightly misspelled):

('1800-01-01 00:00:00'::timestamp)::int

Now, since all values of a DOMAIN are also values of the base type the DOMAIN is
defined as being a subset of, then the sub-expression within the parenthesis
denotes a value that is both a timestamp and a datetime at the same time.

So, if a generic "CAST(timestamp as int)" is already defined, and you define a
"CAST(datetime as int)", then what should the above code (correct for
misspelling) do, or should it fail?

-- Darren Duncan

On Sun, May 15, 2011 at 2:13 AM, Darren Duncan <darren(at)darrenduncan(dot)net> wrote:
>
>  ('1800-01-01 00:00:00'::timestamp)::int
>
> Now, since all values of a DOMAIN are also values of the base type the
> DOMAIN is defined as being a subset of, then the sub-expression within the
> parenthesis denotes a value that is both a timestamp and a datetime at the
> same time.
>
> So, if a generic "CAST(timestamp as int)" is already defined, and you define
> a "CAST(datetime as int)", then what should the above code (correct for
> misspelling) do, or should it fail?
>

Obviously it should run the cast from timestamp to int, why it will
run a cast from a domain?
the other way should be allowed, though... a cast from datetime to int
should first look for cast function using the domain and if it don't
find it then with base type

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL

On Sun, May 15, 2011 at 3:26 AM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
> Obviously it should run the cast from timestamp to int, why it will
> run a cast from a domain?

So let's think about some harder scenarios.

Given two types T1 and T2, and two domains D1 over T1 and D2 over T2,
and a cast from a value of type D1 to type D2, then:

(1) If there is an implicit cast from D1 to D2 and an implicit cast
from T1 to T2, then presumably we should use the cast from D1 to D2,
since it's more specific. Or if none of the available casts involve
domains, but there is a cast of some sort from T1 to T2, then it seems
clear to use that one. But what if we instead have a cast from D1 to
T2 and a cast from T1 to D2? Which one should we prefer? Why?

(2) What happens if there are casts T1 -> T2 and D1 -> D2, but the D1
-> D2 cast is explicit, while the T1 -> T2 cast is on-assignment?
Should we use the D1->D2 cast when the context is explicit and the
T1->T2 when the context is on-assignment? That seems confusing.
Alternatively, we could decide that the on-assignment cast always
beats the explicit cast, even in an explicit-cast context. But that
amounts to ignoring the D1->D2 cast altogether - is that what we want?

(3) What happens if one or both of T1 or T2 are themselves domains
over some other types T3 and T4, respectively? Now there are nine
possible pairings of types (any of D1, T1, T3 with any of D2, T2, T4)
and in each case the available cast could have one of three contexts.
How do we decide which cast wins? Also, we might now need 9 probes
into pg_cast to find all the relevant casts, whereas the current code
needs just one - even in the previous scenario, we might need 4 probes
instead of one. That'll be slower - is it worth it? What's the
performance penalty in an artificially constructed worst case?

(4) What happens if T1 is a domain over T2? Then we have another
option - cast D1 to D2 by smashing it to its base type twice (first to
T1, then to T2), and the re-applying any domain constraint on D2. Is
that preferable to applying a cast from D1 to T1 and then casting to
D2? Is it preferable to applying a cast from D1 to T2 and then
re-applying the domain constraint on D2? Is it preferable to a cast
directly from D1 to D2? And in each case, does the context of the
cast matter?

I'm not throwing these questions out to be flip or to make life
difficult - I'm just saying they need to be thought about, and the
answers don't seem obvious (to me).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Sun, May 15, 2011 at 1:53 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> So let's think about some harder scenarios.
>
> Given two types T1 and T2, and two domains D1 over T1 and D2 over T2,
> and a cast from a value of type D1 to type D2, then:
>

ok. a few fair questions, thanks

> (1) If there is an implicit cast from D1 to D2 and an implicit cast
> from T1 to T2, then presumably we should use the cast from D1 to D2,
> since it's more specific.  Or if none of the available casts involve
> domains, but there is a cast of some sort from T1 to T2, then it seems
> clear to use that one.  But what if we instead have a cast from D1 to
> T2 and a cast from T1 to D2?  Which one should we prefer?  Why?
>

ok, this is the specific problem i said not to touch in my patch...
but, IMHO, we should use T1->D2 on the base that that is the final
type the user wants...

> (2) What happens if there are casts T1 -> T2 and D1 -> D2, but the D1
> -> D2 cast is explicit, while the T1 -> T2 cast is on-assignment?
> Should we use the D1->D2 cast when the context is explicit and the
> T1->T2 when the context is on-assignment?  That seems confusing.
> Alternatively, we could decide that the on-assignment cast always
> beats the explicit cast, even in an explicit-cast context.  But that
> amounts to ignoring the D1->D2 cast altogether - is that what we want?
>

confusing yes. still, imho, we should use the casts based on context
as we always do...

> (3) What happens if one or both of T1 or T2 are themselves domains
> over some other types T3 and T4, respectively?  Now there are nine
> possible pairings of types (any of D1, T1, T3 with any of D2, T2, T4)
> and in each case the available cast could have one of three contexts.
> How do we decide which cast wins?  Also, we might now need 9 probes
> into pg_cast to find all the relevant casts, whereas the current code
> needs just one - even in the previous scenario, we might need 4 probes
> instead of one.  That'll be slower - is it worth it?  What's the
> performance penalty in an artificially constructed worst case?
>
> (4) What happens if T1 is a domain over T2?  Then we have another
> option - cast D1 to D2 by smashing it to its base type twice (first to
> T1, then to T2), and the re-applying any domain constraint on D2.  Is
> that preferable to applying a cast from D1 to T1 and then casting to
> D2?  Is it preferable to applying a cast from D1 to T2 and then
> re-applying the domain constraint on D2?  Is it preferable to a cast
> directly from D1 to D2?  And in each case, does the context of the
> cast matter?
>

these two are very good questions and i can't see a "right" answer for them

> I'm not throwing these questions out to be flip or to make life
> difficult - I'm just saying they need to be thought about, and the
> answers don't seem obvious (to me).
>

still, we have a problem... because we are happily ignoring correctely
created casts...
at least, we should document that casts on domains are ignored and
that we should use the base types instead, maybe even a warning or a
notice when issuing the CREATE CAST command using domains...

make the user think everything is fine when it's not is not a good idea

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL

On Sun, May 15, 2011 at 7:43 PM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
> still, we have a problem... because we are happily ignoring correctely
> created casts...
> at least, we should document that casts on domains are ignored and
> that we should use the base types instead, maybe even a warning or a
> notice when issuing the CREATE CAST command using domains...
>
> make the user think everything is fine when it's not is not a good idea

+1.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Sun, May 15, 2011 at 9:01 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sun, May 15, 2011 at 7:43 PM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
>> still, we have a problem... because we are happily ignoring correctely
>> created casts...
>> at least, we should document that casts on domains are ignored and
>> that we should use the base types instead, maybe even a warning or a
>> notice when issuing the CREATE CAST command using domains...
>>
>> make the user think everything is fine when it's not is not a good idea
>
> +1.
>

ok, i will make a patch for this... btw, why is that we allow to
create those casts at all? or we can deny them?

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL

On Sun, May 15, 2011 at 10:13 PM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
> On Sun, May 15, 2011 at 9:01 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Sun, May 15, 2011 at 7:43 PM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
>>> still, we have a problem... because we are happily ignoring correctely
>>> created casts...
>>> at least, we should document that casts on domains are ignored and
>>> that we should use the base types instead, maybe even a warning or a
>>> notice when issuing the CREATE CAST command using domains...
>>>
>>> make the user think everything is fine when it's not is not a good idea
>>
>> +1.
>>
>
> ok, i will make a patch for this... btw, why is that we allow to
> create those casts at all? or we can deny them?

Before you write the patch... we should probably try to agree on which
of the various options you mention makes most sense.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Sun, May 15, 2011 at 9:14 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> we should probably try to agree on which
> of the various options you mention makes most sense.
>

well... my original patch only handle the simplest case, namely, try
to make the cast that the user wants and if none is defined fall to
the base types...

anything else will complicate things as you shown... actually, things
looks very simple until we start creating trees of domains...
what options look sane to you?

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL

Jaime Casanova wrote:
> On Sun, May 15, 2011 at 9:14 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> we should probably try to agree on which
>> of the various options you mention makes most sense.
>
> well... my original patch only handle the simplest case, namely, try
> to make the cast that the user wants and if none is defined fall to
> the base types...
>
> anything else will complicate things as you shown... actually, things
> looks very simple until we start creating trees of domains...
> what options look sane to you?

The sanest option I see is don't overload the CAST syntax for subtypes. Just
call the foo2bar() function instead. You still get code with the same level of
terseness and that is just as easy to read and understand, and there is no
question of semantics. Also, that solution works right now. -- Darren Duncan

On Tue, May 17, 2011 at 12:29 AM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
> On Sun, May 15, 2011 at 9:14 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>
>> we should probably try to agree on which
>> of the various options you mention makes most sense.
>
> well... my original patch only handle the simplest case, namely, try
> to make the cast that the user wants and if none is defined fall to
> the base types...
>
> anything else will complicate things as you shown... actually, things
> looks very simple until we start creating trees of domains...
> what options look sane to you?

Well, clearly we should document.

The more controversial question is what to do if someone tries to
create such a cast anyway. We could just ignore that as we do now, or
we could throw a NOTICE, WARNING, or ERROR. A NOTICE or WARNING has
the disadvantage that the client might ignore it, and the user be
unaware. An ERROR has the disadvantage that a dump-and-reload from an
earlier version of PostgreSQL might fail - which also means that
pg_upgrade will fail - after the point at which it's disabled the old
cluster. I'm not sure how seriously to take that risk, but it's
something to think about.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> The more controversial question is what to do if someone tries to
> create such a cast anyway.  We could just ignore that as we do now, or
> we could throw a NOTICE, WARNING, or ERROR.

IMHO, not being an error per se but an implementation limitation i
would prefer to send a WARNING

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL

On Tue, May 17, 2011 at 3:11 PM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
> On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>
>> The more controversial question is what to do if someone tries to
>> create such a cast anyway.  We could just ignore that as we do now, or
>> we could throw a NOTICE, WARNING, or ERROR.
>
> IMHO, not being an error per se but an implementation limitation i
> would prefer to send a WARNING

OK, I'm not hearing any objections...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
> On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >
> > The more controversial question is what to do if someone tries to
> > create such a cast anyway. We could just ignore that as we do now, or
> > we could throw a NOTICE, WARNING, or ERROR.
>
> IMHO, not being an error per se but an implementation limitation i
> would prefer to send a WARNING

Implementation limitations are normally reported as errors. I don't see
why it should be different here.

It's debatable whether it's an implementation restriction anyway. If
you want to create casts from or to a domain, maybe distinct types or
type aliases or something like that would be a more appropriate feature
in the long run.

On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
>> On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> >
>> > The more controversial question is what to do if someone tries to
>> > create such a cast anyway.  We could just ignore that as we do now, or
>> > we could throw a NOTICE, WARNING, or ERROR.
>>
>> IMHO, not being an error per se but an implementation limitation i
>> would prefer to send a WARNING
>
> Implementation limitations are normally reported as errors.  I don't see
> why it should be different here.
>

ok, patch reports an error... do we want to backpatch this? if we want
to do so maybe we can backpatch as a warning

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación

On Mon, Jun 13, 2011 at 4:39 AM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
> On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
>>> On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> >
>>> > The more controversial question is what to do if someone tries to
>>> > create such a cast anyway.  We could just ignore that as we do now, or
>>> > we could throw a NOTICE, WARNING, or ERROR.
>>>
>>> IMHO, not being an error per se but an implementation limitation i
>>> would prefer to send a WARNING
>>
>> Implementation limitations are normally reported as errors.  I don't see
>> why it should be different here.
>>
>
> ok, patch reports an error... do we want to backpatch this? if we want
> to do so maybe we can backpatch as a warning

I'm not even really sure I want an ERROR anywhere. If it weren't
something we have accepted previously, I'd be all in favor, but I'm
unconvinced it's worth breaking people's dumps over this.

As far as the back-branches go, I'd be inclined to back-patch only a doc fix.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Jun 13, 2011 at 03:39:39AM -0500, Jaime Casanova wrote:
> On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> > On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
> >> On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >> >
> >> > The more controversial question is what to do if someone tries to
> >> > create such a cast anyway.  We could just ignore that as we do now, or
> >> > we could throw a NOTICE, WARNING, or ERROR.
> >>
> >> IMHO, not being an error per se but an implementation limitation i
> >> would prefer to send a WARNING
> >
> > Implementation limitations are normally reported as errors.  I don't see
> > why it should be different here.
> >
>
> ok, patch reports an error... do we want to backpatch this? if we want
> to do so maybe we can backpatch as a warning

Minor clarification attached.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Where are we on this?

---------------------------------------------------------------------------

David Fetter wrote:
> On Mon, Jun 13, 2011 at 03:39:39AM -0500, Jaime Casanova wrote:
> > On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> > > On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
> > >> On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > >> >
> > >> > The more controversial question is what to do if someone tries to
> > >> > create such a cast anyway. ?We could just ignore that as we do now, or
> > >> > we could throw a NOTICE, WARNING, or ERROR.
> > >>
> > >> IMHO, not being an error per se but an implementation limitation i
> > >> would prefer to send a WARNING
> > >
> > > Implementation limitations are normally reported as errors. ?I don't see
> > > why it should be different here.
> > >
> >
> > ok, patch reports an error... do we want to backpatch this? if we want
> > to do so maybe we can backpatch as a warning
>
> Minor clarification attached.
>
> Cheers,
> David.
> --
> David Fetter <david(at)fetter(dot)org> http://fetter.org/
> Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
> Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
> iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
>
> Remember to vote!
> Consider donating to Postgres: http://www.postgresql.org/about/donate

[ Attachment, skipping... ]

>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On Fri, Oct 14, 2011 at 3:19 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Where are we on this?

Well, I don't know. We had a couple of different ideas on what to do
about it, and I'm not sure anyone was completely in love with any of
the available options.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

David Fetter wrote:
> On Mon, Jun 13, 2011 at 03:39:39AM -0500, Jaime Casanova wrote:
> > On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> > > On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
> > >> On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > >> >
> > >> > The more controversial question is what to do if someone tries to
> > >> > create such a cast anyway. ?We could just ignore that as we do now, or
> > >> > we could throw a NOTICE, WARNING, or ERROR.
> > >>
> > >> IMHO, not being an error per se but an implementation limitation i
> > >> would prefer to send a WARNING
> > >
> > > Implementation limitations are normally reported as errors. ?I don't see
> > > why it should be different here.
> > >
> >
> > ok, patch reports an error... do we want to backpatch this? if we want
> > to do so maybe we can backpatch as a warning
>
> Minor clarification attached.

What happened to this patch for casts on domains from June?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On Mon, Nov 28, 2011 at 9:46 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> David Fetter wrote:
>> On Mon, Jun 13, 2011 at 03:39:39AM -0500, Jaime Casanova wrote:
>> > On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> > > On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
>> > >> On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> > >> >
>> > >> > The more controversial question is what to do if someone tries to
>> > >> > create such a cast anyway. ?We could just ignore that as we do now, or
>> > >> > we could throw a NOTICE, WARNING, or ERROR.
>> > >>
>> > >> IMHO, not being an error per se but an implementation limitation i
>> > >> would prefer to send a WARNING
>> > >
>> > > Implementation limitations are normally reported as errors. ?I don't see
>> > > why it should be different here.
>> > >
>> >
>> > ok, patch reports an error... do we want to backpatch this? if we want
>> > to do so maybe we can backpatch as a warning
>>
>> Minor clarification attached.
>
> What happened to this patch for casts on domains from June?

Well, if we apply this, it has the possibility to break existing
dumps. I think at a minimum if we're going to do this we need to also
modify pg_dump not to dump any such useless casts that may exist in
pre-9.2 databases, so that our usual advice to use the newer pg_dump
will still work.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Nov 28, 2011 at 9:46 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> What happened to this patch for casts on domains from June?

> Well, if we apply this, it has the possibility to break existing
> dumps.

There's also the question of whether there's really much point.
The whole question of what to do with casts on domains is hard,
and I didn't think that thread made any progress towards defining
better behavior. I'd just as soon leave things alone until we
have an idea of what would be better.

regards, tom lane

Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Mon, Nov 28, 2011 at 9:46 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >> What happened to this patch for casts on domains from June?
>
> > Well, if we apply this, it has the possibility to break existing
> > dumps.
>
> There's also the question of whether there's really much point.
> The whole question of what to do with casts on domains is hard,
> and I didn't think that thread made any progress towards defining
> better behavior. I'd just as soon leave things alone until we
> have an idea of what would be better.

OK, fine. That conclusion was not made in the original thread.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> Well, if we apply this, it has the possibility to break existing
>>> dumps.

BTW, it occurs to me that we could dodge that objection, with much less
work than Robert suggests, if we just made the message be a WARNING not
an ERROR. I think that'd do just as well in terms of what the message
could usefully accomplish, ie, steer people away from doing things that
won't work. Still not sure that it's worth doing though,

regards, tom lane

On Tue, Nov 29, 2011 at 10:42 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> Tom Lane wrote:
>>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>>> Well, if we apply this, it has the possibility to break existing
>>>> dumps.
>
> BTW, it occurs to me that we could dodge that objection, with much less
> work than Robert suggests, if we just made the message be a WARNING not
> an ERROR.  I think that'd do just as well in terms of what the message
> could usefully accomplish, ie, steer people away from doing things that
> won't work.  Still not sure that it's worth doing though,
>

i'm fine with a WARNING

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación

On Tue, Nov 29, 2011 at 11:11 AM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
> On Tue, Nov 29, 2011 at 10:42 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>>> Tom Lane wrote:
>>>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>>>> Well, if we apply this, it has the possibility to break existing
>>>>> dumps.
>>
>> BTW, it occurs to me that we could dodge that objection, with much less
>> work than Robert suggests, if we just made the message be a WARNING not
>> an ERROR.  I think that'd do just as well in terms of what the message
>> could usefully accomplish, ie, steer people away from doing things that
>> won't work.  Still not sure that it's worth doing though,
>>
>
> i'm fine with a WARNING

Me too; I suggested it before (so did you).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Tue, Nov 29, 2011 at 10:12 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Nov 29, 2011 at 11:11 AM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
>> On Tue, Nov 29, 2011 at 10:42 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>>>> Tom Lane wrote:
>>>>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>>>>> Well, if we apply this, it has the possibility to break existing
>>>>>> dumps.
>>>
>>> BTW, it occurs to me that we could dodge that objection, with much less
>>> work than Robert suggests, if we just made the message be a WARNING not
>>> an ERROR.  I think that'd do just as well in terms of what the message
>>> could usefully accomplish, ie, steer people away from doing things that
>>> won't work.  Still not sure that it's worth doing though,
>>>
>>
>> i'm fine with a WARNING
>
> Me too; I suggested it before (so did you).
>

are we going to put this warning in this release?

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación

On Tue, Apr 24, 2012 at 3:00 AM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
> are we going to put this warning in this release?

Done.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company