On Mon, Apr 28, 2025 at 9:12 AM Peter Geoghegan wrote:
> On Sun, Apr 27, 2025 at 1:06 PM Mark Dilger
> wrote:
> > I can confirm that your patch fixes the problem, having spent some four
> hours trying to find other test cases which still fail, finding none.
>
> Great.
>
On Sat, Apr 26, 2025 at 8:53 PM Peter Geoghegan wrote:
> On Sat, Apr 26, 2025 at 10:39 PM Mark Dilger
> wrote:
> > Peter, Matthias, thanks kindly for the good work on skipscans!
>
> Thanks!
>
> > I found a test case which fails after commit
> 21a152b37f36c9563d1
1436baf578b4c
>
> Modified Files
> --
> src/backend/access/nbtree/nbtsearch.c | 16 +++
> src/backend/access/nbtree/nbtutils.c | 90
> +++
> src/include/access/nbtree.h | 3 +-
> 3 files changed, 78 insertions(+), 31
On Tue, Mar 4, 2025 at 8:46 AM Peter Eisentraut
wrote:
> On 27.02.25 23:17, Mark Dilger wrote:
> > The logic in equality_ops_are_compatible() was trusting that equality
> > operators found in an opfamily for btree or hash were ok, but not
> > trusting operators found in op
patible and comparison_ops_are_compatible
> were not modified:
>
> * This is trivially true if they are the same operator. Otherwise,
> * we look to see if they can be found in the same btree or hash opfamily.
>
> * This is trivially true if they are the same operator. Othe
r could opt-in or opt-out as they like when running make_hooks.
Does anybody object to this idea in principle? If not, I can put something
like this together from a similar script I already have lying around.
[1] https://www.postgresql.org/message-id/7825.1511902037%40sss.pgh.pa.us
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
