From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jaime Casanova <jaime(at)2ndquadrant(dot)com> |
Cc: | Darren Duncan <darren(at)darrenduncan(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: DOMAINs and CASTs |
Date: | 2011-05-17 17:19:17 |
Message-ID: | BANLkTikYEUDbnw1+PP5bDy-5Cc2p-xnyMw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-05-17 18:02:07 | Re: use less space in xl_xact_commit patch |
Previous Message | David E. Wheeler | 2011-05-17 16:51:14 | Re: Extension Packaging |