From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ALTER TYPE COLLATABLE? |
Date: | 2011-03-06 20:47:17 |
Message-ID: | 1299444437.8831.5.camel@vanquo.pezone.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2011-03-06 21:33:38 | Re: Sync Rep v19 |
Previous Message | Robert Haas | 2011-03-06 19:55:51 | Re: default pg_hba vs replication |