Skip site navigation (1) Skip section navigation (2)

Re: Collations versus record-returning functions

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Collations versus record-returning functions
Date: 2011-03-20 19:26:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
> 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(at)svana(dot)org>
> Patriotism is when love of your own people comes first; nationalism,
> when hate for people other than your own comes first. 
>                                       - Charles de Gaulle

In response to


pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2011-03-20 19:44:43
Subject: Re: WIP patch: collation assignment algorithm rewrite
Previous:From: homDate: 2011-03-20 15:44:29
Subject: Re: I am confused after reading codes of PostgreSQL three week

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group