Re: FuncExpr.collid/OpExpr.collid unworkably serving double duty

Martijn van Oosterhout <kleptog(at)svana(dot)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