pgsql: pg_collation_actual_version() -> pg_collation_current_version().

On 22.02.21 12:28, Thomas Munro wrote:

pg_collation_actual_version() -> pg_collation_current_version().

The new name seems a bit more natural.

Discussion: /messages/by-id/20210117215940.GE8560@telsasoft.com

I don't find where this change was discussed in that thread. I
specifically chose that name to indicate, "not the current version in
the database, but the version the OS thinks it should be". I think the
rename loses that distinction.

On Tue, Feb 23, 2021 at 7:03 PM Peter Eisentraut <peter@eisentraut.org> wrote:

On 22.02.21 12:28, Thomas Munro wrote:

pg_collation_actual_version() -> pg_collation_current_version().

The new name seems a bit more natural.

Discussion: /messages/by-id/20210117215940.GE8560@telsasoft.com

I don't find where this change was discussed in that thread. I
specifically chose that name to indicate, "not the current version in
the database, but the version the OS thinks it should be". I think the
rename loses that distinction.

I understood "actual" to be a way of contrasting with
pg_collation.collversion, which we dropped. Without that, the meaning
of a more typical function name with "current" seemed clearer to me,
and "actual" seemed excessively emphatic. There isn't a concept of a
single "current version in the database" anymore, there's just the set
of relevant versions that were current when each index was built.
Happy to revert the name change if you hate it though, and sorry I
didn't CC you on the thread.

On 23.02.21 08:23, Thomas Munro wrote:

On Tue, Feb 23, 2021 at 7:03 PM Peter Eisentraut <peter@eisentraut.org> wrote:

On 22.02.21 12:28, Thomas Munro wrote:

pg_collation_actual_version() -> pg_collation_current_version().

The new name seems a bit more natural.

Discussion: /messages/by-id/20210117215940.GE8560@telsasoft.com

I don't find where this change was discussed in that thread. I
specifically chose that name to indicate, "not the current version in
the database, but the version the OS thinks it should be". I think the
rename loses that distinction.

I understood "actual" to be a way of contrasting with
pg_collation.collversion, which we dropped. Without that, the meaning
of a more typical function name with "current" seemed clearer to me,
and "actual" seemed excessively emphatic. There isn't a concept of a
single "current version in the database" anymore, there's just the set
of relevant versions that were current when each index was built.
Happy to revert the name change if you hate it though, and sorry I
didn't CC you on the thread.

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.

On Thu, Feb 25, 2021 at 10:49 PM Peter Eisentraut <peter@eisentraut.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.

On 2021-Feb-26, Thomas Munro wrote:

On Thu, Feb 25, 2021 at 10:49 PM Peter Eisentraut <peter@eisentraut.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)