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? Thom >
