Re: DOMAINs and CASTs

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

In response to

Responses

Browse pgsql-hackers by date

  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