From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ALTER TYPE COLLATABLE? |
Date: | 2011-03-02 21:00:56 |
Message-ID: | 22778.1299099656@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On tis, 2011-03-01 at 16:31 -0500, Tom Lane wrote:
>> If a boolean true/false is a sufficient representation of a type's
>> collation property, why isn't the column in pg_type just a boolean?
>> If the idea of storing an OID is to allow reference to a choice of
>> collations, why are we painting ourselves into a corner by dumping
>> it as a boolean?
> The same column is used for base types, which can only have default
> collation or nothing, and domains, which can have any collation.
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.
> We
> could of course also have two separate columns, one typcollatable
> boolean, and the typcollation only used by domains, and an earlier patch
> had that, but as it turned out the code that ends up using this is
> simplest if there is only one column. We could also (probably) support
> arbitrary nondefault collations on base types, but that sounds a bit
> odd, so I wouldn't want to support it yet unless there is a real use
> case.
Well, I think a use case will pop up PDQ --- contrib/citext seems like
the most likely first candidate.
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", but I would just as soon not have a parameter
that's got such an obviously short time-to-live.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2011-03-02 21:02:00 | Re: Sync Rep v17 |
Previous Message | Joe Conway | 2011-03-02 20:54:21 | Re: ALTER TABLE deadlock with concurrent INSERT |