[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

On 24 Jul 2026, at 03:29, Ian Lawrence Barwick <barwick@gmail.com> wrote:

Either way, documenting its existence would be useful to have, IMO.

I can't really come up with an argument for not documenting it, so unless there
are objections I'll apply the docs patch.

--
Daniel Gustafsson

Hi All,

+1 for documenting it.

I took a look at the patch, it applies cleanly to master and the resulting
SGML is well-formed.

The description text mirrors pg_client_encoding()'s existing entry
("Returns current client encoding name."), which seems right to me for
consistency. The declared "name" return type matches pg_proc.dat, too.

It might also be worth mentioning in the description that this returns the
server encoding, i.e. the same value as current_setting('server_encoding').
Feel free to ignore if you'd rather keep the entry minimal.

Regards,
Surya Poondla

On 27 Jul 2026, at 20:10, surya poondla <suryapoondla4@gmail.com> wrote:

+1 for documenting it.

Pushed.

It might also be worth mentioning in the description that this returns the server encoding, i.e. the same value as current_setting('server_encoding').
Feel free to ignore if you'd rather keep the entry minimal.

That could be applied in many places, so I opted out of doing in this single
instance and instead went with consistency with the client encoding function.

--
Daniel Gustafsson

2026年7月29日(水) 19:50 Daniel Gustafsson <daniel@yesql.se>:

On 27 Jul 2026, at 20:10, surya poondla <suryapoondla4@gmail.com> wrote:

+1 for documenting it.

Pushed.

Thanks!

It might also be worth mentioning in the description that this returns the server encoding, i.e. the same value as current_setting('server_encoding').
Feel free to ignore if you'd rather keep the entry minimal.

That could be applied in many places, so I opted out of doing in this single
instance and instead went with consistency with the client encoding function.

Yup, if at all that would be a separate operation.

Regards

Ian Barwick