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
Attachments:
v1-0001-Fix-comment-in-btree_gist-1.8-1.9.sql.patchtext/x-patch; charset=UTF-8; name=v1-0001-Fix-comment-in-btree_gist-1.8-1.9.sql.patchDownload+1-2
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
Attachments:
v1-0001-Collapse-last-two-releases-of-btree_gist-into-1.8.patchtext/x-patch; charset=UTF-8; name=v1-0001-Collapse-last-two-releases-of-btree_gist-into-1.8.patchDownload+199-200
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