Thread

1. DOMAINs and CASTs

   Jaime Casanova <jaime@2ndquadrant.com> — 2011-05-14T18:28:14Z

   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
   

2. Re: DOMAINs and CASTs

   Tom Lane <tgl@sss.pgh.pa.us> — 2011-05-14T22:13:28Z

   Jaime Casanova <jaime@2ndquadrant.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
   
   

3. Re: DOMAINs and CASTs

   Jaime Casanova <jaime@2ndquadrant.com> — 2011-05-15T00:29:35Z

   On Sat, May 14, 2011 at 5:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
   > Jaime Casanova <jaime@2ndquadrant.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
   
   

4. Re: DOMAINs and CASTs

   Darren Duncan <darren@darrenduncan.net> — 2011-05-15T01:42:25Z

   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
   
   

5. Re: DOMAINs and CASTs

   Darren Duncan <darren@darrenduncan.net> — 2011-05-15T01:46:58Z

   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
   
   

6. Re: DOMAINs and CASTs

   Gelman <igny03@verizon.net> — 2011-05-15T01:56:05Z

   ----- Original Message ----- 
   From: "Darren Duncan" <darren@darrenduncan.net>
   To: "Jaime Casanova" <jaime@2ndquadrant.com>
   Cc: "PostgreSQL-development" <pgsql-hackers@postgresql.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@postgresql.org)
   > To make changes to your subscription:
   > http://www.postgresql.org/mailpref/pgsql-hackers 
   
   
   

7. Re: DOMAINs and CASTs

   Jaime Casanova <jaime@2ndquadrant.com> — 2011-05-15T06:43:05Z

   On Sat, May 14, 2011 at 8:42 PM, Darren Duncan <darren@darrenduncan.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
   
   

8. Re: DOMAINs and CASTs

   Darren Duncan <darren@darrenduncan.net> — 2011-05-15T07:13:16Z

   Jaime Casanova wrote:
   > On Sat, May 14, 2011 at 8:42 PM, Darren Duncan <darren@darrenduncan.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
   
   

9. Re: DOMAINs and CASTs

   Jaime Casanova <jaime@2ndquadrant.com> — 2011-05-15T07:26:16Z

   On Sun, May 15, 2011 at 2:13 AM, Darren Duncan <darren@darrenduncan.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
   
   

10. Re: DOMAINs and CASTs

    Robert Haas <robertmhaas@gmail.com> — 2011-05-15T18:53:22Z

    On Sun, May 15, 2011 at 3:26 AM, Jaime Casanova <jaime@2ndquadrant.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
    
    

11. Re: DOMAINs and CASTs

    Jaime Casanova <jaime@2ndquadrant.com> — 2011-05-15T23:43:43Z

    On Sun, May 15, 2011 at 1:53 PM, Robert Haas <robertmhaas@gmail.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
    
    

12. Re: DOMAINs and CASTs

    Robert Haas <robertmhaas@gmail.com> — 2011-05-16T02:01:03Z

    On Sun, May 15, 2011 at 7:43 PM, Jaime Casanova <jaime@2ndquadrant.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
    
    

13. Re: DOMAINs and CASTs

    Jaime Casanova <jaime@2ndquadrant.com> — 2011-05-16T02:13:07Z

    On Sun, May 15, 2011 at 9:01 PM, Robert Haas <robertmhaas@gmail.com> wrote:
    > On Sun, May 15, 2011 at 7:43 PM, Jaime Casanova <jaime@2ndquadrant.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
    
    

14. Re: DOMAINs and CASTs

    Robert Haas <robertmhaas@gmail.com> — 2011-05-16T02:14:45Z

    On Sun, May 15, 2011 at 10:13 PM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
    > On Sun, May 15, 2011 at 9:01 PM, Robert Haas <robertmhaas@gmail.com> wrote:
    >> On Sun, May 15, 2011 at 7:43 PM, Jaime Casanova <jaime@2ndquadrant.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
    
    

15. Re: DOMAINs and CASTs

    Jaime Casanova <jaime@2ndquadrant.com> — 2011-05-17T04:29:21Z

    On Sun, May 15, 2011 at 9:14 PM, Robert Haas <robertmhaas@gmail.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
    
    

16. Re: DOMAINs and CASTs

    Darren Duncan <darren@darrenduncan.net> — 2011-05-17T05:11:14Z

    Jaime Casanova wrote:
    > On Sun, May 15, 2011 at 9:14 PM, Robert Haas <robertmhaas@gmail.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
    
    

17. Re: DOMAINs and CASTs

    Robert Haas <robertmhaas@gmail.com> — 2011-05-17T17:19:17Z

    On Tue, May 17, 2011 at 12:29 AM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
    > On Sun, May 15, 2011 at 9:14 PM, Robert Haas <robertmhaas@gmail.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
    
    

18. Re: DOMAINs and CASTs

    Jaime Casanova <jaime@2ndquadrant.com> — 2011-05-17T19:11:49Z

    On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas@gmail.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
    
    

19. Re: DOMAINs and CASTs

    Robert Haas <robertmhaas@gmail.com> — 2011-05-19T14:19:24Z

    On Tue, May 17, 2011 at 3:11 PM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
    > On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas@gmail.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
    
    

20. Re: DOMAINs and CASTs

    Peter Eisentraut <peter_e@gmx.net> — 2011-06-06T11:36:30Z

    On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
    > On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas@gmail.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.
    
    
    

21. Re: DOMAINs and CASTs

    Jaime Casanova <jaime@2ndquadrant.com> — 2011-06-13T08:39:39Z

    On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut <peter_e@gmx.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@gmail.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
    

22. Re: DOMAINs and CASTs

    Robert Haas <robertmhaas@gmail.com> — 2011-06-13T13:44:33Z

    On Mon, Jun 13, 2011 at 4:39 AM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
    > On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut <peter_e@gmx.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@gmail.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
    
    

23. Re: DOMAINs and CASTs

    David Fetter <david@fetter.org> — 2011-06-13T15:34:02Z

    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@gmx.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@gmail.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@fetter.org> http://fetter.org/
    Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
    Skype: davidfetter      XMPP: david.fetter@gmail.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
    

24. Re: DOMAINs and CASTs

    Bruce Momjian <bruce@momjian.us> — 2011-10-14T19:19:14Z

    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@gmx.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@gmail.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@fetter.org> http://fetter.org/
    > Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
    > Skype: davidfetter      XMPP: david.fetter@gmail.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@postgresql.org)
    > To make changes to your subscription:
    > http://www.postgresql.org/mailpref/pgsql-hackers
    
    -- 
      Bruce Momjian  <bruce@momjian.us>        http://momjian.us
      EnterpriseDB                             http://enterprisedb.com
    
      + It's impossible for everything to be true. +
    
    

25. Re: DOMAINs and CASTs

    Robert Haas <robertmhaas@gmail.com> — 2011-10-14T22:02:20Z

    On Fri, Oct 14, 2011 at 3:19 PM, Bruce Momjian <bruce@momjian.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
    
    

26. Re: DOMAINs and CASTs

    Bruce Momjian <bruce@momjian.us> — 2011-11-29T02:46:07Z

    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@gmx.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@gmail.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@momjian.us>        http://momjian.us
      EnterpriseDB                             http://enterprisedb.com
    
      + It's impossible for everything to be true. +
    

27. Re: DOMAINs and CASTs

    Robert Haas <robertmhaas@gmail.com> — 2011-11-29T14:16:23Z

    On Mon, Nov 28, 2011 at 9:46 PM, Bruce Momjian <bruce@momjian.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@gmx.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@gmail.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
    
    

28. Re: DOMAINs and CASTs

    Tom Lane <tgl@sss.pgh.pa.us> — 2011-11-29T15:36:18Z

    Robert Haas <robertmhaas@gmail.com> writes:
    > On Mon, Nov 28, 2011 at 9:46 PM, Bruce Momjian <bruce@momjian.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
    
    

29. Re: DOMAINs and CASTs

    Bruce Momjian <bruce@momjian.us> — 2011-11-29T15:37:38Z

    Tom Lane wrote:
    > Robert Haas <robertmhaas@gmail.com> writes:
    > > On Mon, Nov 28, 2011 at 9:46 PM, Bruce Momjian <bruce@momjian.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@momjian.us>        http://momjian.us
      EnterpriseDB                             http://enterprisedb.com
    
      + It's impossible for everything to be true. +
    
    

30. Re: DOMAINs and CASTs

    Tom Lane <tgl@sss.pgh.pa.us> — 2011-11-29T15:42:59Z

    Bruce Momjian <bruce@momjian.us> writes:
    > Tom Lane wrote:
    >> Robert Haas <robertmhaas@gmail.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
    
    

31. Re: DOMAINs and CASTs

    Jaime Casanova <jaime@2ndquadrant.com> — 2011-11-29T16:11:25Z

    On Tue, Nov 29, 2011 at 10:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
    > Bruce Momjian <bruce@momjian.us> writes:
    >> Tom Lane wrote:
    >>> Robert Haas <robertmhaas@gmail.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
    
    

32. Re: DOMAINs and CASTs

    Robert Haas <robertmhaas@gmail.com> — 2011-11-30T03:12:13Z

    On Tue, Nov 29, 2011 at 11:11 AM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
    > On Tue, Nov 29, 2011 at 10:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
    >> Bruce Momjian <bruce@momjian.us> writes:
    >>> Tom Lane wrote:
    >>>> Robert Haas <robertmhaas@gmail.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
    
    

33. Re: DOMAINs and CASTs

    Jaime Casanova <jaime@2ndquadrant.com> — 2012-04-24T07:00:32Z

    On Tue, Nov 29, 2011 at 10:12 PM, Robert Haas <robertmhaas@gmail.com> wrote:
    > On Tue, Nov 29, 2011 at 11:11 AM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
    >> On Tue, Nov 29, 2011 at 10:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
    >>> Bruce Momjian <bruce@momjian.us> writes:
    >>>> Tom Lane wrote:
    >>>>> Robert Haas <robertmhaas@gmail.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
    
    

34. Re: DOMAINs and CASTs

    Robert Haas <robertmhaas@gmail.com> — 2012-04-24T13:21:38Z

    On Tue, Apr 24, 2012 at 3:00 AM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
    > are we going to put this warning in this release?
    
    Done.
    
    -- 
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise PostgreSQL Company