upstream/postgresql
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-03-23 02:43:22 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Sort out table_open vs. relation_open in rewriter

Browse source 
table_open() is a wrapper around relation_open() that checks that the
relkind is table-like and gives a user-facing error message if not.
It is best used in directly user-facing areas to check that the user
used the right kind of command for the relkind.  In internal uses
where the relkind was previously checked from the user's perspective,
table_open() is not necessary and might even be confusing if it were
to give out-of-context error messages.

In rewriteHandler.c, there were several such table_open() calls, which
this changes to relation_open().  This currently doesn't make a
difference, but there are plans to have other relkinds that could
appear in the rewriter but that shouldn't be accessible via
table-specific commands, and this clears the way for that.

Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/6d3fef19-a420-4e11-8235-8ea534bf2080%40eisentraut.org
Discussion: https://www.postgresql.org/message-id/flat/a855795d-e697-4fa5-8698-d20122126567@eisentraut.org
This commit is contained in:
Peter Eisentraut 2026-03-11 09:22:11 +01:00
parent 82467f627b
commit d537f59fbb
1 changed files with 6 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
src/backend/rewrite/rewriteHandler.c
View file

@ -195,7 +195,7 @@ AcquireRewriteLocks(Query *parsetree,
else
lockmode = rte->rellockmode;
rel = table_open(rte->relid, lockmode);
rel = relation_open(rte->relid, lockmode);
/*
* While we have the relation open, update the RTE's relkind,
@ -203,7 +203,7 @@ AcquireRewriteLocks(Query *parsetree,
*/
rte->relkind = rel->rd_rel->relkind;
table_close(rel, NoLock);
relation_close(rel, NoLock);
break;
case RTE_JOIN:
@ -2116,7 +2116,7 @@ fireRIRrules(Query *parsetree, List *activeRIRs)
* We can use NoLock here since either the parser or
* AcquireRewriteLocks should have locked the rel already.
*/
rel = table_open(rte->relid, NoLock);
rel = relation_open(rte->relid, NoLock);
/*
* Collect the RIR rules that we must apply
@ -2226,7 +2226,7 @@ fireRIRrules(Query *parsetree, List *activeRIRs)
rte->relkind != RELKIND_PARTITIONED_TABLE))
continue;
rel = table_open(rte->relid, NoLock);
rel = relation_open(rte->relid, NoLock);
/*
* Fetch any new security quals that must be applied to this RTE.
@ -3445,7 +3445,7 @@ rewriteTargetView(Query *parsetree, Relation view)
* already have the right lock!) Since it will become the query target
* relation, RowExclusiveLock is always the right thing.
*/
base_rel = table_open(base_rte->relid, RowExclusiveLock);
base_rel = relation_open(base_rte->relid, RowExclusiveLock);
/*
* While we have the relation open, update the RTE's relkind, just in case
@ -4021,7 +4021,7 @@ RewriteQuery(Query *parsetree, List *rewrite_events, int orig_rt_length,
* We can use NoLock here since either the parser or
* AcquireRewriteLocks should have locked the rel already.
*/
rt_entry_relation = table_open(rt_entry->relid, NoLock);
rt_entry_relation = relation_open(rt_entry->relid, NoLock);
/*
* Rewrite the targetlist as needed for the command type.