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?
