On Tue, 22 Apr 2025 at 22:25, Tom Lane wrote:
>
> Pavel Borisov writes:
> > On Tue, 22 Apr 2025 at 21:13, Tom Lane wrote:
> >> BTW, you forgot to update expected/float4-misrounded-input.out.
>
> > Added in v3. Thanks for a mention!
>
> v3 LGTM, pushed.
Thank you!
Regards,
Pavel
Pavel Borisov writes:
> On Tue, 22 Apr 2025 at 21:13, Tom Lane wrote:
>> BTW, you forgot to update expected/float4-misrounded-input.out.
> Added in v3. Thanks for a mention!
v3 LGTM, pushed.
regards, tom lane
Hi, Tom!
On Tue, 22 Apr 2025 at 21:13, Tom Lane wrote:
>
> Pavel Borisov writes:
> > On Tue, 22 Apr 2025 at 20:22, Alexander Korotkov
> > wrote:
> >> On Tue, Apr 22, 2025 at 7:20 PM Tom Lane wrote:
> >>> Alexander Korotkov writes:
> I'd like to add that float4.out not only assumes that
Pavel Borisov writes:
> On Tue, 22 Apr 2025 at 20:22, Alexander Korotkov wrote:
>> On Tue, Apr 22, 2025 at 7:20 PM Tom Lane wrote:
>>> Alexander Korotkov writes:
I'd like to add that float4.out not only assumes that insert-ordering is
preserved (this could be more-or-less portable bet
Hi!
On Tue, 22 Apr 2025 at 20:22, Alexander Korotkov wrote:
>
> On Tue, Apr 22, 2025 at 7:20 PM Tom Lane wrote:
> > Alexander Korotkov writes:
> > > I'd like to add that float4.out not only assumes that insert-ordering is
> > > preserved (this could be more-or-less portable between table AMs).
On Tue, Apr 22, 2025 at 7:20 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > I'd like to add that float4.out not only assumes that insert-ordering is
> > preserved (this could be more-or-less portable between table AMs). It also
> > assumes the way UPDATE moves updated rows. That seems quit
Alexander Korotkov writes:
> I'd like to add that float4.out not only assumes that insert-ordering is
> preserved (this could be more-or-less portable between table AMs). It also
> assumes the way UPDATE moves updated rows. That seems quite
> heap-specific. You can see in the following fragment
On Tue, Apr 22, 2025 at 5:57 PM Pavel Borisov
wrote:
> On Tue, 22 Apr 2025 at 18:40, Pavel Borisov
wrote:
> > On Tue, 22 Apr 2025 at 18:23, Tom Lane wrote:
> > >
> > > Pavel Borisov writes:
> > > > It's not a big problem, but propose a simple fix for the tests. It
> > > > just adds ORDER BY 1 t
On Tue, 22 Apr 2025 at 18:40, Pavel Borisov wrote:
>
> Hi, Tom!
>
> On Tue, 22 Apr 2025 at 18:23, Tom Lane wrote:
> >
> > Pavel Borisov writes:
> > > It's not a big problem, but propose a simple fix for the tests. It
> > > just adds ORDER BY 1 to all relevant float4 and floa8 queries.
> >
> > Yo
Hi, Tom!
On Tue, 22 Apr 2025 at 18:23, Tom Lane wrote:
>
> Pavel Borisov writes:
> > It's not a big problem, but propose a simple fix for the tests. It
> > just adds ORDER BY 1 to all relevant float4 and floa8 queries.
>
> You do realize that this problem is hardly confined to the
> float4 and f
Pavel Borisov writes:
> It's not a big problem, but propose a simple fix for the tests. It
> just adds ORDER BY 1 to all relevant float4 and floa8 queries.
You do realize that this problem is hardly confined to the
float4 and float8 tests? To a first approximation, a table AM
that fails to prese
Hi Pavel,
> It's not a big problem, but propose a simple fix for the tests. It
> just adds ORDER BY 1 to all relevant float4 and floa8 queries.
Thanks for the patch. That's a good change IMO.
> I don't
> have a strong opinion about backpatching this, but as the patch
> changes only regression te
Hi, hackers!
I noticed that SELECT results in float4 and float8 tests lack ORDER BY
clauses. This makes test results depend on the current heap/MVCC
implementation.
If I try to run the float8 test on a table created with a different
access method provided by an extension, I'm getting results orde
13 matches
Mail list logo
