On ons, 2011-03-02 at 16:00 -0500, Tom Lane wrote: > That seems like a 100% arbitrary distinction between base types and > domains, to the detriment of base types, which is odd since in most > other ways base types are much more flexible than domains.
Well, base types don't support check constraints either. So conceptually, there is a useful distinction, namely that domains are sort of a macro for a column definition. > Well, I think a use case will pop up PDQ --- contrib/citext seems like > the most likely first candidate. Why would citext need a nondefault default collation? OK, something that will probably be opened for discussion in 9.2 is fitting case-insensitivity into the core collation/type system, and then this might come into play, but we don't really know how the details of that will look like. > I guess that since the CREATE TYPE parameter is named COLLATABLE, > we could extend in an upward-compatible way by adding a parameter > "COLLATION name", Yes. > but I would just as soon not have a parameter that's got such an > obviously short time-to-live. I think the COLLATABLE parameter would still have a reason to live even then. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers