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 |
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 |