[PATCH] Rename "getdatabaseencoding()" to "pg_database_encoding()", and document

On 17 Jul 2026, at 08:44, Ian Lawrence Barwick <barwick@gmail.com> wrote:

It was noted here [1] that we have the undocumented SQL function
"getdatabaseencoding()", used mainly in regression tests and a couple
of psql queries. While considering a documentation patch, it occurred
to me that it's a horrible function name which doesn't look like other
public functions, and we already have "pg_client_encoding()", so why not
rename it to match that while we're at it?

This function seems to be referred to in extensions, how about adding keeping
the existin name and adding the new name as an alias? It would keep existing
code from breaking and cause less churn in the code.

--
Daniel Gustafsson

On Fri, 17 Jul 2026, 08:24 Daniel Gustafsson, <daniel@yesql.se> wrote:

On 17 Jul 2026, at 08:44, Ian Lawrence Barwick <barwick@gmail.com>

wrote:

It was noted here [1] that we have the undocumented SQL function
"getdatabaseencoding()", used mainly in regression tests and a couple
of psql queries. While considering a documentation patch, it occurred
to me that it's a horrible function name which doesn't look like other
public functions, and we already have "pg_client_encoding()", so why not
rename it to match that while we're at it?

This function seems to be referred to in extensions, how about adding
keeping
the existin name and adding the new name as an alias? It would keep
existing
code from breaking and cause less churn in the code.

Why don't extensions use current_setting('server_encoding')?

Thom

Daniel Gustafsson <daniel@yesql.se> writes:

On 17 Jul 2026, at 08:44, Ian Lawrence Barwick <barwick@gmail.com> wrote:
It was noted here [1] that we have the undocumented SQL function
"getdatabaseencoding()", used mainly in regression tests and a couple
of psql queries. While considering a documentation patch, it occurred
to me that it's a horrible function name which doesn't look like other
public functions, and we already have "pg_client_encoding()", so why not
rename it to match that while we're at it?

This function seems to be referred to in extensions, how about adding keeping
the existin name and adding the new name as an alias? It would keep existing
code from breaking and cause less churn in the code.

Yeah, the odds that we would remove the old name (without a multi-year
deprecation period) are zero, full stop.

However, I can't really get excited about this proposal in the first
place. There are plenty of ugly and inconsistent names in Postgres,
and an enormous amount of more-valuable work to do.

regards, tom lane

2026年7月17日(金) 23:29 Tom Lane <tgl@sss.pgh.pa.us>:

Daniel Gustafsson <daniel@yesql.se> writes:

On 17 Jul 2026, at 08:44, Ian Lawrence Barwick <barwick@gmail.com> wrote:
It was noted here [1] that we have the undocumented SQL function
"getdatabaseencoding()", used mainly in regression tests and a couple
of psql queries. While considering a documentation patch, it occurred
to me that it's a horrible function name which doesn't look like other
public functions, and we already have "pg_client_encoding()", so why not
rename it to match that while we're at it?

This function seems to be referred to in extensions, how about adding keeping
the existin name and adding the new name as an alias? It would keep existing
code from breaking and cause less churn in the code.

Yeah, the odds that we would remove the old name (without a multi-year
deprecation period) are zero, full stop.

However, I can't really get excited about this proposal in the first
place. There are plenty of ugly and inconsistent names in Postgres,
and an enormous amount of more-valuable work to do.

Makes sense.

Here's a patch to at least document it, in the table "Other String
Functions and Operators"
(as "pg_client_encoding()" is already there).

Regards

Ian Barwick

On Sat, 18 Jul 2026, 06:05 Ian Lawrence Barwick, <barwick@gmail.com> wrote:

2026年7月17日(金) 23:29 Tom Lane <tgl@sss.pgh.pa.us>:

Daniel Gustafsson <daniel@yesql.se> writes:

On 17 Jul 2026, at 08:44, Ian Lawrence Barwick <barwick@gmail.com>

wrote:

It was noted here [1] that we have the undocumented SQL function
"getdatabaseencoding()", used mainly in regression tests and a couple
of psql queries. While considering a documentation patch, it occurred
to me that it's a horrible function name which doesn't look like other
public functions, and we already have "pg_client_encoding()", so why

not

rename it to match that while we're at it?

This function seems to be referred to in extensions, how about adding

keeping

the existin name and adding the new name as an alias? It would keep

existing

code from breaking and cause less churn in the code.

Yeah, the odds that we would remove the old name (without a multi-year
deprecation period) are zero, full stop.

However, I can't really get excited about this proposal in the first
place. There are plenty of ugly and inconsistent names in Postgres,
and an enormous amount of more-valuable work to do.

Makes sense.

Here's a patch to at least document it, in the table "Other String
Functions and Operators"
(as "pg_client_encoding()" is already there).

I would go in the opposite direction; announce its deprecation, and mention
the alternative in the release notes. Surely we don't want to make it more
difficult to get rid of?

Thom

2026年7月18日(土) 16:57 Thom Brown <thom@linux.com>:

On Sat, 18 Jul 2026, 06:05 Ian Lawrence Barwick, <barwick@gmail.com> wrote:

2026年7月17日(金) 23:29 Tom Lane <tgl@sss.pgh.pa.us>:

Daniel Gustafsson <daniel@yesql.se> writes:

On 17 Jul 2026, at 08:44, Ian Lawrence Barwick <barwick@gmail.com> wrote:
It was noted here [1] that we have the undocumented SQL function
"getdatabaseencoding()", used mainly in regression tests and a couple
of psql queries. While considering a documentation patch, it occurred
to me that it's a horrible function name which doesn't look like other
public functions, and we already have "pg_client_encoding()", so why not
rename it to match that while we're at it?

This function seems to be referred to in extensions, how about adding keeping
the existin name and adding the new name as an alias? It would keep existing
code from breaking and cause less churn in the code.

Yeah, the odds that we would remove the old name (without a multi-year
deprecation period) are zero, full stop.

However, I can't really get excited about this proposal in the first
place. There are plenty of ugly and inconsistent names in Postgres,
and an enormous amount of more-valuable work to do.

Makes sense.

Here's a patch to at least document it, in the table "Other String
Functions and Operators"
(as "pg_client_encoding()" is already there).

I would go in the opposite direction; announce its deprecation, and mention the alternative in the release notes. Surely we don't want to make it more difficult to get rid of?

There doesn't seem to be consensus to do that. Either way, documenting its
existence would be useful to have, IMO.

Regards

Ian Barwick