Peter Eisentraut <peter_e@gmx.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
