Horton

Thread

Commits

  1. Revert "pg_collation_actual_version() -> pg_collation_current_version()."

  2. pg_collation_actual_version() -> pg_collation_current_version().

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

    Thomas Munro <tmunro@postgresql.org> — 2021-02-22T11:28:52Z

    pg_collation_actual_version() -> pg_collation_current_version().

The new name seems a bit more natural.

Discussion: https://postgr.es/m/20210117215940.GE8560%40telsasoft.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/9cf184cc0599b6e65e7e5ecd9d91cd42e278bcd8

Modified Files
--------------
doc/src/sgml/func.sgml                         |  8 ++++----
src/backend/commands/collationcmds.c           |  2 +-
src/backend/utils/adt/pg_locale.c              | 14 +++++++-------
src/include/catalog/catversion.h               |  2 +-
src/include/catalog/pg_proc.dat                |  4 ++--
src/test/regress/expected/collate.icu.utf8.out |  6 +++---
src/test/regress/sql/collate.icu.utf8.sql      |  6 +++---
7 files changed, 21 insertions(+), 21 deletions(-)

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

    Peter Eisentraut <peter@eisentraut.org> — 2021-02-23T06:03:12Z

    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: https://postgr.es/m/20210117215940.GE8560%40telsasoft.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.

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

    Thomas Munro <thomas.munro@gmail.com> — 2021-02-23T07:23:19Z

    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: https://postgr.es/m/20210117215940.GE8560%40telsasoft.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.

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

    Peter Eisentraut <peter@eisentraut.org> — 2021-02-25T09:49:02Z

    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: https://postgr.es/m/20210117215940.GE8560%40telsasoft.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.

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

    Thomas Munro <thomas.munro@gmail.com> — 2021-02-26T03:13:54Z

    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.

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

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2022-09-04T07:38:33Z

    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)