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.
