On Tue, May 17, 2011 at 12:29 AM, Jaime Casanova <ja...@2ndquadrant.com> wrote: > On Sun, May 15, 2011 at 9:14 PM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
