surya poondla <suryapoondla4@gmail.com> writes:
> My observation is the user, current* functions collation is "C" collation
> and when a "C" collation is passed as a parameter, it converts all the
> parameters to use the "C" collation.
Yeah, Jian diagnosed this correctly: the "user" pseudo-function has
output type "name" and therefore inherits the "C" collation attached
to that type, which then propagates through the cast to text. Then
when we come to resolve the collation for to_upper_first() to use,
we have one input that is unknown and hence has no collation to offer,
and one that has "C" collation, so "C" collation wins. You'd need an
explicit COLLATE clause to override that.
> I am currently using gdb to debug more and will work on a patch based on my
> findings.
AFAIK all this behavior is mandated by the SQL standard. Well, the
fact that the non-standard type "name" is given "C" collation isn't
to be found in the spec, but the rules for deducing the collation of
an expression definitely are. If you want to propose a patch about
this, it had better come with a well-reasoned argument why our current
behavior violates the spec and the patch fixes that.
regards, tom lane
