On 2022-11-17 Th 17:11, Andrew Dunstan wrote:
> On 2022-11-04 Fr 10:06, Jehan-Guillaume de Rorthais wrote:
>> On Thu, 3 Nov 2022 13:11:18 -0500
>> Justin Pryzby wrote:
>>
>>> On Tue, Jun 28, 2022 at 06:17:40PM -0400, Andrew Dunstan wrote:
Nice catch, but this looks like massive overkill. I
On 2022-11-04 Fr 10:06, Jehan-Guillaume de Rorthais wrote:
> On Thu, 3 Nov 2022 13:11:18 -0500
> Justin Pryzby wrote:
>
>> On Tue, Jun 28, 2022 at 06:17:40PM -0400, Andrew Dunstan wrote:
>>> Nice catch, but this looks like massive overkill. I think we can very
>>> simply fix the test in just a f
On Thu, 3 Nov 2022 13:11:18 -0500
Justin Pryzby wrote:
> On Tue, Jun 28, 2022 at 06:17:40PM -0400, Andrew Dunstan wrote:
> > 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
On Tue, Jun 28, 2022 at 06:17:40PM -0400, Andrew Dunstan wrote:
> 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.
>
> It was never intended to be able to compare markers li
On Tue, 5 Jul 2022 09:59:42 -0400
Andrew Dunstan wrote:
> On 2022-07-03 Su 16:12, Jehan-Guillaume de Rorthais wrote:
> > On Sun, 3 Jul 2022 10:40:21 -0400
> > Andrew Dunstan wrote:
> >
> >> On 2022-06-29 We 05:09, Jehan-Guillaume de Rorthais wrote:
> >>> On Tue, 28 Jun 2022 18:17:40 -0400
>
On 2022-07-03 Su 16:12, Jehan-Guillaume de Rorthais wrote:
> On Sun, 3 Jul 2022 10:40:21 -0400
> Andrew Dunstan wrote:
>
>> On 2022-06-29 We 05:09, Jehan-Guillaume de Rorthais wrote:
>>> On Tue, 28 Jun 2022 18:17:40 -0400
>>> Andrew Dunstan wrote:
>>>
On 2022-06-28 Tu 16:53, Jehan-Guilla
On Sun, 3 Jul 2022 10:40:21 -0400
Andrew Dunstan wrote:
> On 2022-06-29 We 05:09, Jehan-Guillaume de Rorthais wrote:
> > On Tue, 28 Jun 2022 18:17:40 -0400
> > Andrew Dunstan wrote:
> >
> >> On 2022-06-28 Tu 16:53, Jehan-Guillaume de Rorthais wrote:
> >>> ...
> >>> A better fix would be to s
On 2022-06-29 We 05:09, Jehan-Guillaume de Rorthais wrote:
> On Tue, 28 Jun 2022 18:17:40 -0400
> Andrew Dunstan 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
On Tue, 28 Jun 2022 18:17:40 -0400
Andrew Dunstan 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 t
On Tue, Jun 28, 2022 at 06:17:40PM -0400, Andrew Dunstan wrote:
> 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.
>
> It was never intended to be able to compare markers li
On 2022-06-28 Tu 16:53, Jehan-Guillaume de Rorthais wrote:
> Hi,
>
> I found a comparaison bug when using the PostgreSQL::Version module. See:
>
> $ perl -I. -MPostgreSQL::Version -le '
> my $v = PostgreSQL::Version->new("9.6");
>
> print "not 9.6 > 9.0" unless $v > 9.0;
> print
Hi,
I found a comparaison bug when using the PostgreSQL::Version module. See:
$ perl -I. -MPostgreSQL::Version -le '
my $v = PostgreSQL::Version->new("9.6");
print "not 9.6 > 9.0" unless $v > 9.0;
print "not 9.6 < 9.0" unless $v < 9.0;
print "9.6 <= 9.0"if $v <= 9.0
12 matches
Mail list logo