| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | some validate_relation_kind() tidying |
| Date: | 2026-02-18 15:15:09 |
| Message-ID: | 6d3fef19-a420-4e11-8235-8ea534bf2080@eisentraut.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
We have three different functions called validate_relation_kind(), namely in
src/backend/access/index/indexam.c
src/backend/access/sequence/sequence.c
src/backend/access/table/table.c
These all check which relkinds are permitted by index_open(),
sequence_open(), and table_open(), respectively, which are each wrappers
around relation_open() (which accepts any relkind).
I always found the one in table.c a little too mysterious, because it
just checks which relkinds it does *not* want, and so if you want to
know whether a particular relkind is suitable for table_open(), you need
to do additional research and check what all the possible relkinds are
and so on, and there is no real explanation why those choices were made.
I think it would be clearer and more robust and also more consistent
with the other ones if we flipped that around and listed the ones that
are acceptable and why.
Secondly, the sequence.c one was probably copied from the table.c one,
but I think we can make the error message a bit more direct by just
saying "... is not a sequence" instead of "cannot open relation".
These are the two attached patches. This is just something I found
while working on something else nearby.
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Change-error-message-for-sequence-validate_relation_.patch | text/plain | 2.2 KB |
| 0002-Flip-logic-in-table-validate_relation_kind.patch | text/plain | 2.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Álvaro Herrera | 2026-02-18 15:16:59 | Re: Killing off anoncvs.postgresql.org |
| Previous Message | Nathan Bossart | 2026-02-18 15:13:19 | Re: Discrepancy in --no-tablespaces behavior between Tar and Plain-text formats |