| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alexander Nestorov <alexandernst(at)gmail(dot)com> |
| Cc: | Maxime Schoemans <maxime(dot)schoemans(at)enterprisedb(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers mailing list <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] btree_gist: add cross-type integer operator support for GiST |
| Date: | 2026-09-25 18:54:45 |
| Message-ID: | 2011408.1790362485@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alexander Nestorov <alexandernst(at)gmail(dot)com> writes:
> Attaching v7 patchset.
I spent a bit of time looking at v7. I think you have made the wrong
choice here:
> To let the cross-type path reuse gbt_num_consistent(), all comparison
> callbacks are now invoked as f(query, key): query on the left, key on
> the right
The index AMs are generally built on the principle that an index
condition looks like "index_key OP query_value", which is why
all the code looks like it does. So I object to changes like
case BTLessEqualStrategyNumber:
if (is_leaf)
- retval = tinfo->f_le(key->lower, query, flinfo);
+ retval = tinfo->f_ge(query, key->lower, flinfo);
else
retval = lower_is_below_query();
break;
It is confusing and error-prone for the code to be written exactly
backwards from the strategy code name. So I think you should undo
all those changes and instead change whatever you were trying to
avoid changing. I really doubt that that will lead to a messier
patch. (Maybe it'd be smart to split 0001 into two steps, one
that syncs whatever order-of-parameters problem you see and then
one that adds cross-type stuff on top of that.)
I'm also confused by all the names involving "q4" and the like.
Maybe that conveys something to your mind, but it conveys nothing
to mine, and I don't see any comments explaining the naming
convention. It'd probably be good to use slightly longer names.
Lastly, please avoid making random whitespace changes in places
away from your code changes. Those just distract reviewers,
and it's not usually apparent that the change is an improvement
anyway. Revising line breaks for no very good reason is likewise
a drag on reviewers' attention.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2026-09-25 18:54:58 | Re: Cleaning up pgcrypto/crypt-des.c to avoid compiler warnings |
| Previous Message | Ayush Tiwari | 2026-09-25 18:37:30 | Re: Cleaning up pgcrypto/crypt-des.c to avoid compiler warnings |