Re: [HACKERS] Collations versus record-returning functions

2011-03-22 Thread Peter Eisentraut
On sön, 2011-03-20 at 20:26 +0100, Martijn van Oosterhout wrote: 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. Yeah, that's answer #4. The composite types themselves are not

Re: [HACKERS] Collations versus record-returning functions

2011-03-20 Thread Martijn van Oosterhout
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)

Re: [HACKERS] Collations versus record-returning functions

2011-03-19 Thread Tom Lane
I wrote: ISTM there are basically three things we might do about this: (1) Decide that the patch's behavior is correct and what's embodied in the regression expected file is wrong. (2) Allow collations to propagate up through nodes that deliver noncollatable outputs. (3) Decide that

[HACKERS] Collations versus record-returning functions

2011-03-18 Thread Tom Lane
I'm making pretty good progress on the task of splitting input and output collations for expression nodes. There remains one case in the regression tests that is giving a non-expected result. It involves this function: CREATE FUNCTION dup (f1 anyelement, f2 out anyelement, f3 out anyarray)