Re: pgsql: pg_collation_actual_version() -> pg_collation_current_version().

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: pg_collation_actual_version() -> pg_collation_current_version().
Date: 2022-09-04 07:38:33
Message-ID: 20220904073833.oi56o5nqbs6hrf6y@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On 2021-Feb-26, Thomas Munro wrote:

> On Thu, Feb 25, 2021 at 10:49 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
> > Seeing that explanation, I think that's even more of a reason to avoid
> > the name "current" and use something strikingly different.
> >
> > In any case, this function name has been around for some years now and
> > renaming it just for taste reasons seems unnecessary.
>
> I guess my unspoken assumption was that anyone using this in a query
> is probably comparing it with collversion and thus already has a query
> that needs to be rewritten for v14, and therefore it's not a bad time
> to clean up some naming. But that argument is moot if you don't even
> agree that the new name's an improvement, so... reverted.

18 months later I find myself translating this message:

#: utils/init/postinit.c:457
msgid "template database \"%s\" has a collation version, but no actual collation version could be determined"

and I have absolutely no idea what to translate it to. What does it
*mean*? I think if it does mean something important, there should be a
"translator:" comment next to it.

However, looking at get_collation_actual_version, I think returning NULL
is unexpected anyway; it appears that in all cases where something
failed, it has already reported an error internally. Also, several
callers seem to ignore the possibility of it returning NULL. So I
wonder if we can just turn this ereport() into an elog() and call it a
day.

The word "actual" is very seldom used in catalogued server messages. We
only have these few:

msgid "template database \"%s\" has a collation version, but no actual collation version could be determined"
msgid "could not determine actual type of argument declared %s"
msgid "RADIUS response from %s has corrupt length: %d (actual length %d)"
msgid "ShmemIndex entry size is wrong for data structure \"%s\": expected %zu, actual %zu"
msgid "could not determine actual enum type"
msgid "collation \"%s\" has no actual version, but a version was recorded"
msgid "could not determine actual result type for function \"%s\" declared to return type %s"
msgid "database \"%s\" has no actual collation version, but a version was recorded"

and my strategy so far is to translate it to "real" (meaning "true") or
just ignore the word altogether, which gives good results IMO. But in
this particular it looks like it's a very critical part of the message.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"No me acuerdo, pero no es cierto. No es cierto, y si fuera cierto,
no me acuerdo." (Augusto Pinochet a una corte de justicia)

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Alvaro Herrera 2022-09-04 07:54:50 Re: pgsql: Prefetch data referenced by the WAL, take II.
Previous Message John Naylor 2022-09-04 06:19:56 Re: pgsql: Build all Flex files standalone

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2022-09-04 07:54:50 Re: pgsql: Prefetch data referenced by the WAL, take II.
Previous Message Michael Paquier 2022-09-04 07:25:18 Re: freeing LDAPMessage in CheckLDAPAuth