Remove getpgusername()

On 03/07/2026 18:35, Thom Brown wrote:

Hi,

This function has been deprecated for 25 years (version 7.1). Can we
finally tear it out?

Heh, +1 from me. One could also argue that it doesn't really do any
harm. But I'm generally in favor of removing deprecated stuff even if
they're not actively getting in the way, after enough time has passed.

On a related note, the "getdatabaseencoding()" function doesn't seem to
be documented...

- Heikki

Hi Thom,

Nice catch on the getpgusername().

+1 in the direction of removing deprecated stuff if they are not actively
being used in any version.

Regards,
Surya Poondla

On Sun, Jul 05, 2026 at 02:09:19AM +0300, Heikki Linnakangas wrote:

On 03/07/2026 18:35, Thom Brown wrote:

This function has been deprecated for 25 years (version 7.1). Can we
finally tear it out?

Heh, +1 from me. One could also argue that it doesn't really do any harm.
But I'm generally in favor of removing deprecated stuff even if they're not
actively getting in the way, after enough time has passed.

That's what I call a historical artifact. Removing it looks to be
simply a cleanup of pg_proc.dat. Will do so if there are no
objections, freeing an OID is not a bad thing here.

On a related note, the "getdatabaseencoding()" function doesn't seem to be
documented...

Documenting it would not hurt, yes. We use it a lot in the regression
tests, perhaps some extensions would gain some portability ideas if we
publish a few words about it.
--
Michael

On Thu, Jul 16, 2026 at 08:00:51AM +0900, Michael Paquier wrote:

That's what I call a historical artifact. Removing it looks to be
simply a cleanup of pg_proc.dat. Will do so if there are no
objections, freeing an OID is not a bad thing here.

And done this part.

Documenting it would not hurt, yes. We use it a lot in the regression
tests, perhaps some extensions would gain some portability ideas if we
publish a few words about it.

For this part, if somebody has a patch, feel free.
--
Michael

2026年7月17日(金) 7:51 Michael Paquier <michael@paquier.xyz>:

On Thu, Jul 16, 2026 at 08:00:51AM +0900, Michael Paquier wrote:

That's what I call a historical artifact. Removing it looks to be
simply a cleanup of pg_proc.dat. Will do so if there are no
objections, freeing an OID is not a bad thing here.

And done this part.

Documenting it would not hurt, yes. We use it a lot in the regression
tests, perhaps some extensions would gain some portability ideas if we
publish a few words about it.

For this part, if somebody has a patch, feel free.

I was feeling free, but the more I looked at it, the more horribly
inconsistent and ugly
"getdatabaseencoding()" is as a public SQL function name, and we have
"pg_client_encoding()" already, so might as well rename it?

Patch in separate thread:
/messages/by-id/CAB8KJ=iQQ3j1ZzJkgF_CGF5TvJsugp6JFOrS-LB7kT=XivV_Vg@mail.gmail.com

Regards

Ian Barwick

2026年7月17日(金) 15:49 Ian Lawrence Barwick <barwick@gmail.com>:

2026年7月17日(金) 7:51 Michael Paquier <michael@paquier.xyz>:

On Thu, Jul 16, 2026 at 08:00:51AM +0900, Michael Paquier wrote:

That's what I call a historical artifact. Removing it looks to be
simply a cleanup of pg_proc.dat. Will do so if there are no
objections, freeing an OID is not a bad thing here.

And done this part.

Documenting it would not hurt, yes. We use it a lot in the regression
tests, perhaps some extensions would gain some portability ideas if we
publish a few words about it.

For this part, if somebody has a patch, feel free.

I was feeling free, but the more I looked at it, the more horribly
inconsistent and ugly
"getdatabaseencoding()" is as a public SQL function name, and we have
"pg_client_encoding()" already, so might as well rename it?

Patch in separate thread:
/messages/by-id/CAB8KJ=iQQ3j1ZzJkgF_CGF5TvJsugp6JFOrS-LB7kT=XivV_Vg@mail.gmail.com

The idea was not popular, so I submitted a plain documentation
patch: https://commitfest.postgresql.org/patch/7029/

Regards

Ian Barwick