On Fri, Mar 18, 2011 at 10:40:53PM -0400, Tom Lane wrote:
> (2) Allow collations to propagate up through nodes that deliver
> noncollatable outputs.
I don't think this is the goal. Only strings types are collatable, as
you point out.
> * Something like
> row('a' collate "C", 'b' collate "en_US")
> doesn't have a resolvable collation, but I don't think we want it
> to throw an error.
Well, it doesn't. But it returns a rowtype and the string columns in
the row type would carry a collation and I don't think they'd have to
be the same. row is not a function really.
> * If composites are collatable, one would logically expect a table's
> rowtype to inherit the common collation of its columns (if there is
> one). This is problematic because then the rowtype collation can change
> after ALTER TABLE ADD COLUMN/DROP COLUMN/ALTER COLUMN TYPE, which is
> something we can't support even if it seemed like a good idea.
Indeed not.
A rowtype has an order, determined by the fields within it. Those
fields may be strings and so may have a collation. Doesn't seem
particularly magical to me.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patriotism is when love of your own people comes first; nationalism,
> when hate for people other than your own comes first.
> - Charles de Gaulle