Re: DOMAINs and CASTs - Mailing list pgsql-hackers

From Robert Haas
Subject Re: DOMAINs and CASTs
Date
Msg-id BANLkTikYEUDbnw1+PP5bDy-5Cc2p-xnyMw@mail.gmail.com
Whole thread Raw
In response to Re: DOMAINs and CASTs  (Jaime Casanova <jaime@2ndquadrant.com>)
Responses Re: DOMAINs and CASTs  (Jaime Casanova <jaime@2ndquadrant.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: Extension Packaging
Next
From: Robert Haas
Date:
Subject: Re: use less space in xl_xact_commit patch