Re: pgsql: Generalize hash and ordering support in amapi

2025-03-08 Thread Peter Eisentraut
On 07.03.25 19:50, Tom Lane wrote: Peter Eisentraut writes: I have committed fixes for these issues along the lines you suggested. Thanks. There is a typo in hashhandler: - amroutine->amcancrosscompare = true; + amroutine->amconsistentequality = true; + amroutine->amconsistentequality

Re: pgsql: Generalize hash and ordering support in amapi

2025-03-07 Thread Tom Lane
Peter Eisentraut writes: > I have committed fixes for these issues along the lines you suggested. Thanks. There is a typo in hashhandler: - amroutine->amcancrosscompare = true; + amroutine->amconsistentequality = true; + amroutine->amconsistentequality = false; The second line should be

Re: pgsql: Generalize hash and ordering support in amapi

2025-03-07 Thread Peter Eisentraut
On 04.03.25 18:35, Tom Lane wrote: In any case, my gripe was less about the name of the flag and more about the lack of a clear specification of what it means. "does AM support cross-type comparisons" doesn't get the job done. Maybe we can fit /* do operators within an opfamily have consi

Re: pgsql: Generalize hash and ordering support in amapi

2025-03-04 Thread Tom Lane
Peter Eisentraut writes: > 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 opfamilies of other AMs. Now, after the >> patch, other

Re: pgsql: Generalize hash and ordering support in amapi

2025-03-04 Thread Mark Dilger
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 opfamilies of other AMs.

Re: pgsql: Generalize hash and ordering support in amapi

2025-03-04 Thread Peter Eisentraut
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 opfamilies of other AMs.  Now, after the patch, other AMs can be marked as suitable.  That's

Re: pgsql: Generalize hash and ordering support in amapi

2025-03-01 Thread Peter Eisentraut
On 27.02.25 23:17, Mark Dilger wrote: On Thu, Feb 27, 2025 at 8:27 AM Tom Lane > wrote: Peter Eisentraut mailto:pe...@eisentraut.org>> writes: > Generalize hash and ordering support in amapi > Stop comparing access method OID values against HASH_AM_OID

Re: pgsql: Generalize hash and ordering support in amapi

2025-02-27 Thread Mark Dilger
On Thu, Feb 27, 2025 at 8:27 AM Tom Lane wrote: > Peter Eisentraut writes: > > Generalize hash and ordering support in amapi > > Stop comparing access method OID values against HASH_AM_OID and > > BTREE_AM_OID, and instead check the IndexAmRoutine for an index to see > > if it advertises its abi

pgsql: Generalize hash and ordering support in amapi

2025-02-27 Thread Peter Eisentraut
Generalize hash and ordering support in amapi Stop comparing access method OID values against HASH_AM_OID and BTREE_AM_OID, and instead check the IndexAmRoutine for an index to see if it advertises its ability to perform the necessary ordering, hashing, or cross-type comparing functionality. A fi

Re: pgsql: Generalize hash and ordering support in amapi

2025-02-27 Thread Tom Lane
Peter Eisentraut writes: > Generalize hash and ordering support in amapi > Stop comparing access method OID values against HASH_AM_OID and > BTREE_AM_OID, and instead check the IndexAmRoutine for an index to see > if it advertises its ability to perform the necessary ordering, > hashing, or cross-