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

2026年7月18日(土) 16:57 Thom Brown <thom(at)linux(dot)com>:
>
> On Sat, 18 Jul 2026, 06:05 Ian Lawrence Barwick, <barwick(at)gmail(dot)com> wrote:
>>
>> 2026年7月17日(金) 23:29 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> >
>> > Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> > >> On 17 Jul 2026, at 08:44, Ian Lawrence Barwick <barwick(at)gmail(dot)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