Martijn van Oosterhout <klep...@svana.org> writes: > On Thu, Mar 10, 2011 at 05:51:31PM -0500, Tom Lane wrote: >> No, that's not what I'm on about. Consider >> >> (((A COLLATE X) || B) || (C COLLATE Y)) < (D COLLATE Z)
> The rules are essentially as described here: > http://msdn.microsoft.com/en-us/library/ms179886.aspx Hmm ... that's an interesting document, but I'm not at all sure that it intends to describe the same rules that are in the SQL standard. In particular I don't believe that their notion of coercible-default matches the standard. > In my implementation I needed to expand this to the general set of > operators postgresql supported and relaxed this to only consider > arguments to the function/operator that had the same type as the > resulting type of the function/operator, since that's the only thing > that makes sense. Yeah, that corresponds to Transact-SQL's distinction between functions that take a string and produce a string, versus those that produce a string without any string inputs. But I don't see anything justifying such a distinction in the text of the standard. Also note that the TSQL doc explicitly points out that collation labels can be carried up through changes of character string types, so I think you're wrong to say that collation is only carried through functions that produce exactly the same type as their input. I'd say collation labels propagate through any function that has both collatable input(s) and a collatable result type. In any case, I am sure that that what this describes is not what our current code does :-(, and that we can't get anywhere close to this with the existing infrastructure. So at this point I'm thinking that the safest approach is to rip out the result-collation caching fields and perform collation assignment in a parsing post-pass. That will allow us to revise the collation assignment algorithm without further catversion bumps. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers