2026年7月18日(土) 16:57 Thom Brown <[email protected]>: > > On Sat, 18 Jul 2026, 06:05 Ian Lawrence Barwick, <[email protected]> wrote: >> >> 2026年7月17日(金) 23:29 Tom Lane <[email protected]>: >> > >> > Daniel Gustafsson <[email protected]> writes: >> > >> On 17 Jul 2026, at 08:44, Ian Lawrence Barwick <[email protected]> >> > >> 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
