From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dmytro Astapov <dastapov@gmail.com>
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Using current_user as an argument of pl/pgsql function affects
 collation of other arguments
In-reply-to: 
 <CAFQUnFhL0xCA9Y+OkBR73F1wwpAT0vDshVt0aTFdb7FkiGhMXA@mail.gmail.com>
References: 
 <CAFQUnFhL0xCA9Y+OkBR73F1wwpAT0vDshVt0aTFdb7FkiGhMXA@mail.gmail.com>
Comments: In-reply-to Dmytro Astapov <dastapov@gmail.com>
	message dated "Wed, 14 Aug 2024 15:09:17 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <613284.1723753952.1@sss.pgh.pa.us>
Date: Thu, 15 Aug 2024 16:32:32 -0400
Message-ID: <613285.1723753952@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/613285.1723753952%40sss.pgh.pa.us>
Precedence: bulk

Dmytro Astapov <dastapov@gmail.com> writes:
> As the subject implies, I am observing that
> current_user/session_user/current_database/current_schema, when used as an
> argument for pl/pgsql function, could affect execution plans of unrelated
> queries inside that pl/pgsql function -- because they seemingly affect
> collation for other arguments (I am not 100% sure about this last claim,
> but the observed effects suggest that this might be the case).

This is expected behavior.  Those functions return type "name" not
"text", and "name" is considered to have C collation.  Then, in
a call such as

	select_test('1',current_user);

that is the only source of collation in the expression and so
select_test is invoked with an input collation of "C", rather
than whatever the database's default is.

The most robust solution probably is to write

       explain select *
         from tbl
         where id = id_to_update COLLATE "default"

			regards, tom lane