Re: Fix proposal for comparaison bugs in PostgreSQL::Version

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Fix proposal for comparaison bugs in PostgreSQL::Version
Дата
Msg-id b7772fde-9c65-f56a-cff4-2ef34fc72ccf@dunslane.net
обсуждение исходный текст
Ответ на Re: Fix proposal for comparaison bugs in PostgreSQL::Version  (Jehan-Guillaume de Rorthais <jgdr@dalibo.com>)
Ответы Re: Fix proposal for comparaison bugs in PostgreSQL::Version  (Jehan-Guillaume de Rorthais <jgdr@dalibo.com>)
Список pgsql-hackers
On 2022-06-29 We 05:09, Jehan-Guillaume de Rorthais wrote:
> On Tue, 28 Jun 2022 18:17:40 -0400
> Andrew Dunstan <andrew@dunslane.net> wrote:
>
>> On 2022-06-28 Tu 16:53, Jehan-Guillaume de Rorthais wrote:
>>> ...
>>> A better fix would be to store the version internally as version_num that
>>> are trivial to compute and compare. Please, find in attachment an
>>> implementation of this.
>>>
>>> The patch is a bit bigger because it improved the devel version to support
>>> rc/beta/alpha comparison like 14rc2 > 14rc1.
>>>
>>> Moreover, it adds a bunch of TAP tests to check various use cases.  
>>
>> Nice catch, but this looks like massive overkill. I think we can very
>> simply fix the test in just a few lines of code, instead of a 190 line
>> fix and a 130 line TAP test.
> I explained why the patch was a little bit larger than required: it fixes the
> bugs and do a little bit more. The _version_cmp sub is shorter and easier to
> understand, I use multi-line code where I could probably fold them in a
> one-liner, added some comments... Anyway, I don't feel the number of line
> changed is "massive". But I can probably remove some code and shrink some other
> if it is really important...
>
> Moreover, to be honest, I don't mind the number of additional lines of TAP
> tests. Especially since it runs really, really fast and doesn't hurt day-to-day
> devs as it is independent from other TAP tests anyway. It could be 1k, if it
> runs fast, is meaningful and helps avoiding futur regressions, I would welcome
> the addition.


I don't see the point of having a TAP test at all. We have TAP tests for
testing the substantive products we test, not for the test suite
infrastructure. Otherwise, where will we stop? Shall we have tests for
the things that test the test suite?


>
> If we really want to save some bytes, I have a two lines worth of code fix that
> looks more readable to me than fixing _version_cmp:
>
> +++ b/src/test/perl/PostgreSQL/Version.pm
> @@ -92,9 +92,13 @@ sub new
>         # Split into an array
>         my @numbers = split(/\./, $arg);
>  
> +       # make sure all digit of the array-represented version are set so we can
> +       # keep _version_cmp code as a "simple" digit-to-digit comparison loop
> +       $numbers[$_] += 0 for 0..3;
> +
>         # Treat development versions as having a minor/micro version one less than
>         # the first released version of that branch.
> -       push @numbers, -1 if ($devel);
> +       $numbers[3] = -1 if $devel;
>  
>         $devel ||= "";


I don't see why this is any more readable.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: making relfilenodes 56 bits
Следующее
От: Robert Haas
Дата:
Сообщение: Re: PSA: Autoconf has risen from the dead