Re: Index AM API cleanup

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Alex Wang <alex(dot)wang(at)enterprisedb(dot)com>, Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
Subject: Re: Index AM API cleanup
Date: 2025-02-04 13:31:51
Message-ID: cae32874-5399-43e0-a5d5-c04e2edad1c5@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 03.02.25 12:08, Peter Eisentraut wrote:
> Yeah, actually this turned out to be unnecessary, because you can easily
> obtain the AM OID from the passed-in opclass ID.  So I have fixed it
> that way.  I have committed this whole patch set now with the mentioned
> adjustments.  I'll post a rebased version of the main patch set soon.

I picked off two more patches from the full patch series that can be
dealt with easily. These are

- Support non-btree indexes for foreign keys
- Allow non-btree speculative insertion indexes

(v19-0012 and v19-0013)

The version of these patches that were posted in the v19 bundle replaced
the hardcoded comparison with BTREE_AM_OID by a check against
(indirectly) amcanunique. But I think that is not necessary, because at
that point we already know that we are dealing with a unique index. The
reason for the check against BTREE_AM_OID was that we didn't have a way
to get the right strategy number for other index methods. But now we
have, so we can use the strategy translation functions and we don't need
to check for btree-ness anymore.

See attached patches.

Attachment Content-Type Size
v19.3-0001-Support-non-btree-indexes-for-foreign-keys.patch text/plain 4.1 KB
v19.3-0002-Allow-non-btree-speculative-insertion-indexes.patch text/plain 1.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2025-02-04 13:52:35 Re: NOT ENFORCED constraint feature
Previous Message Bertrand Drouvot 2025-02-04 13:24:03 Re: Avoid orphaned objects dependencies, take 3