Re: Possibly a bug

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: surya poondla <suryapoondla4(at)gmail(dot)com>
Cc: jian he <jian(dot)universality(at)gmail(dot)com>, Анатолий <anatoly(at)email(dot)su>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Possibly a bug
Date: 2026-02-10 22:34:37
Message-ID: 3976350.1770762877@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

surya poondla <suryapoondla4(at)gmail(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Raphaël Perissat 2026-02-11 09:56:53 Re: BUG #19400: Memory leak in checkpointer and startup processes on PostgreSQL 18
Previous Message surya poondla 2026-02-10 21:51:11 Re: Possibly a bug