Re: DOMAINs and CASTs
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Jaime Casanova <jaime@2ndquadrant.com>
Cc: Darren Duncan <darren@darrenduncan.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-05-17T17:19:17Z
Lists: 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