Thread: Fix comment in btree_gist--1.8--1.9.sql

Hello Hackers,

I noticed that the comment at the top of btree_gist--1.8--1.9.sql says it is the 1.7--1.8 file. Here 
is a one-line patch to fix that.

A related question: In the v18 release we are adding two upgrade files: btree_gist--1.7--1.8.sql and 
btree_gist--1.8-1.9.sql. Why not collapse them into one? Technically we briefly had 
btree_gist--1.7--1.8.sql in 17devel, but it was reverted before release. Would you like a patch 
combining these files? Is it too late for that?

Yours,

-- 
Paul              ~{:-)
pj@illuminatedcomputing.com

On Tue, Jul 08, 2025 at 04:49:30PM -0700, Paul Jungwirth wrote:
> I noticed that the comment at the top of btree_gist--1.8--1.9.sql says it is
> the 1.7--1.8 file. Here is a one-line patch to fix that.
>
> A related question: In the v18 release we are adding two upgrade files:
> btree_gist--1.7--1.8.sql and btree_gist--1.8-1.9.sql. Why not collapse them
> into one? Technically we briefly had btree_gist--1.7--1.8.sql in 17devel,
> but it was reverted before release. Would you like a patch combining these
> files? Is it too late for that?

It would be too late once the branch is officially released, and we
are still in a position where it is possible to combine both.  Let's
do so for REL_18_STABLE, having two upgrade paths for a single major
version is just extra work for no benefit.

For PGSS, we've added several things in a single major release, always
limiting ourselves to a single new version bump.
--
Michael

Michael Paquier <michael@paquier.xyz> writes:
> On Tue, Jul 08, 2025 at 04:49:30PM -0700, Paul Jungwirth wrote:
>> A related question: In the v18 release we are adding two upgrade files:
>> btree_gist--1.7--1.8.sql and btree_gist--1.8-1.9.sql. Why not collapse them
>> into one? Technically we briefly had btree_gist--1.7--1.8.sql in 17devel,
>> but it was reverted before release. Would you like a patch combining these
>> files? Is it too late for that?

> It would be too late once the branch is officially released, and we
> are still in a position where it is possible to combine both.  Let's
> do so for REL_18_STABLE, having two upgrade paths for a single major
> version is just extra work for no benefit.

+1 for merging those two while we still can.

            regards, tom lane

On 7/9/25 08:51, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> On Tue, Jul 08, 2025 at 04:49:30PM -0700, Paul Jungwirth wrote:
>>> A related question: In the v18 release we are adding two upgrade files:
>>> btree_gist--1.7--1.8.sql and btree_gist--1.8-1.9.sql. Why not collapse them
>>> into one? Technically we briefly had btree_gist--1.7--1.8.sql in 17devel,
>>> but it was reverted before release. Would you like a patch combining these
>>> files? Is it too late for that?
> 
>> It would be too late once the branch is officially released, and we
>> are still in a position where it is possible to combine both.  Let's
>> do so for REL_18_STABLE, having two upgrade paths for a single major
>> version is just extra work for no benefit.
> 
> +1 for merging those two while we still can.

Patch attached, based on REL_18_STABLE.

I considered putting the sortsupport functions first, since they have a lower support function 
number, but I thought defining them in the same order as we've been doing was a tiny bit safer. 
Maybe that is superstitious.

Yours,

-- 
Paul              ~{:-)
pj@illuminatedcomputing.com

Paul Jungwirth <pj@illuminatedcomputing.com> writes:
> On 7/9/25 08:51, Tom Lane wrote:
>> +1 for merging those two while we still can.

> Patch attached, based on REL_18_STABLE.

> I considered putting the sortsupport functions first, since they have a lower support function
> number, but I thought defining them in the same order as we've been doing was a tiny bit safer.
> Maybe that is superstitious.

Yeah, I'd be inclined to swap them.  I dislike code that has no
ordering principle other than feature development order.

LGTM other than that nit.  Michael, do you want to do the
honors, or shall I?

            regards, tom lane

On Wed, Jul 09, 2025 at 01:52:08PM -0400, Tom Lane wrote:
>> I considered putting the sortsupport functions first, since they have a lower support function
>> number, but I thought defining them in the same order as we've been doing was a tiny bit safer.
>> Maybe that is superstitious.
>
> Yeah, I'd be inclined to swap them.  I dislike code that has no
> ordering principle other than feature development order.

Ordering them by number in the unified script makes more sense here.

> LGTM other than that nit.  Michael, do you want to do the
> honors, or shall I?

Sure, I can look at that today.
--
Michael

On 7/9/25 16:16, Michael Paquier wrote:
> On Wed, Jul 09, 2025 at 01:52:08PM -0400, Tom Lane wrote:
>>> I considered putting the sortsupport functions first, since they have a lower support function
>>> number, but I thought defining them in the same order as we've been doing was a tiny bit safer.
>>> Maybe that is superstitious.
>>
>> Yeah, I'd be inclined to swap them.  I dislike code that has no
>> ordering principle other than feature development order.
> 
> Ordering them by number in the unified script makes more sense here.

Here is a patch with the new order.

Yours,

-- 
Paul              ~{:-)
pj@illuminatedcomputing.com

On Wed, Jul 09, 2025 at 06:21:05PM -0700, Paul Jungwirth wrote:
> Here is a patch with the new order.

Thanks, done.
--
Michael