On Sun, Oct 15, 2023 at 05:12:58PM -0400, Tom Lane wrote:
> Peter Geoghegan writes:
> > On Sat, Oct 14, 2023 at 7:02 PM Tom Lane wrote:
> >> Noah Misch writes:
> >>> That's right. We don't have a standard that installcheck of v13.N will
> >>> have
> >>> zero diffs on an initdb from v13.0.
>
>
Peter Geoghegan writes:
> On Sat, Oct 14, 2023 at 7:02 PM Tom Lane wrote:
>> Noah Misch writes:
>>> That's right. We don't have a standard that installcheck of v13.N will have
>>> zero diffs on an initdb from v13.0.
>> Um ... don't we? I do not recall very many cases where we changed
>> initi
On Sat, Oct 14, 2023 at 7:02 PM Tom Lane wrote:
> Noah Misch writes:
> > That's right. We don't have a standard that installcheck of v13.N will have
> > zero diffs on an initdb from v13.0.
>
> Um ... don't we? I do not recall very many cases where we changed
> initial catalog contents at all in
Noah Misch writes:
> On Sat, Oct 14, 2023 at 08:27:58PM -0400, Tom Lane wrote:
>> Well, that's indeed going to be a pain for affected people, but
>> it doesn't seem like a reason to also break installcheck.
> That's right. We don't have a standard that installcheck of v13.N will have
> zero diff
On Sat, Oct 14, 2023 at 08:27:58PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Sat, Oct 14, 2023 at 07:45:21PM -0400, Tom Lane wrote:
> >> Hmm, I'm not sure that that last is a good idea. The upshot of this
> >> (because of the opr_sanity.out change) is that "make installcheck"
> >> will f
Noah Misch writes:
> On Sat, Oct 14, 2023 at 07:45:21PM -0400, Tom Lane wrote:
>> Hmm, I'm not sure that that last is a good idea. The upshot of this
>> (because of the opr_sanity.out change) is that "make installcheck"
>> will fail against existing back-branch installations. That seems
>> more
On Sat, Oct 14, 2023 at 07:45:21PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > ... This fix makes interval_ops simply omit the support function,
> > like numeric_ops does. Back-pack to v13, where btequalimage() first
> > appeared. In back branches, for the benefit of old catalog content,
> >
Noah Misch writes:
> ... This fix makes interval_ops simply omit the support function,
> like numeric_ops does. Back-pack to v13, where btequalimage() first
> appeared. In back branches, for the benefit of old catalog content,
> btequalimage() code will return false for type "interval". Going
>
Dissociate btequalimage() from interval_ops, ending its deduplication.
Under interval_ops, some equal values are distinguishable. One such
pair is '24:00:00' and '1 day'. With that being so, btequalimage()
breaches the documented contract for the "equalimage" btree support
function. This can ca
Dissociate btequalimage() from interval_ops, ending its deduplication.
Under interval_ops, some equal values are distinguishable. One such
pair is '24:00:00' and '1 day'. With that being so, btequalimage()
breaches the documented contract for the "equalimage" btree support
function. This can ca
Dissociate btequalimage() from interval_ops, ending its deduplication.
Under interval_ops, some equal values are distinguishable. One such
pair is '24:00:00' and '1 day'. With that being so, btequalimage()
breaches the documented contract for the "equalimage" btree support
function. This can ca
Dissociate btequalimage() from interval_ops, ending its deduplication.
Under interval_ops, some equal values are distinguishable. One such
pair is '24:00:00' and '1 day'. With that being so, btequalimage()
breaches the documented contract for the "equalimage" btree support
function. This can ca
Dissociate btequalimage() from interval_ops, ending its deduplication.
Under interval_ops, some equal values are distinguishable. One such
pair is '24:00:00' and '1 day'. With that being so, btequalimage()
breaches the documented contract for the "equalimage" btree support
function. This can ca
13 matches
Mail list logo
