Обсуждение: Simplify pg_collation.collversion for Windows libc

Hi,

Currently the libc collation version for Windows has two components
coming from the NLSVERSIONINFOEX structure [1]
dwNLSVersion and dwDefinedVersion

So we get version numbers looking like this (with 16 beta1):

postgres=# select collversion,count(*) from pg_collation group by
collversion;
  collversion  | count
---------------+-------
           |     5
 1539.5,1539.5 |  1457
(2 rows)

According to [1] the second number is obsolete, and AFAICS we should
expose only the first.

<quote>
dwDefinedVersion

    Defined version. This value is used to track changes in the repertoire
    of Unicode code points. The value increments when the Unicode
    repertoire is extended, for example, if more characters are defined.

    Starting with Windows 8: Deprecated. Use dwNLSVersion instead.
</quote>

PFA a patch implementing that suggestion.


[1]
https://learn.microsoft.com/en-us/windows/win32/api/winnls/ns-winnls-nlsversioninfoex


Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/
Twitter: @DanielVerite

On Mon, Jun 5, 2023 at 12:56 PM Daniel Verite <daniel@manitou-mail.org> wrote:
> postgres=# select collversion,count(*) from pg_collation group by
> collversion;
>   collversion  | count
> ---------------+-------
>                |     5
>  1539.5,1539.5 |  1457
> (2 rows)
>
> According to [1] the second number is obsolete, and AFAICS we should
> expose only the first.

Would it be a good idea to remove or ignore the trailing /,*$/
somewhere, perhaps during pg_upgrade, to avoid bogus version mismatch
warnings?

On 06.06.23 03:21, Thomas Munro wrote:
> On Mon, Jun 5, 2023 at 12:56 PM Daniel Verite <daniel@manitou-mail.org> wrote:
>> postgres=# select collversion,count(*) from pg_collation group by
>> collversion;
>>    collversion  | count
>> ---------------+-------
>>                 |     5
>>   1539.5,1539.5 |  1457
>> (2 rows)
>>
>> According to [1] the second number is obsolete, and AFAICS we should
>> expose only the first.
> 
> Would it be a good idea to remove or ignore the trailing /,*$/
> somewhere, perhaps during pg_upgrade, to avoid bogus version mismatch
> warnings?

I wonder whether it's worth dealing with this, versus just leaving it 
all alone.