Sort out table_open vs. relation_open in rewriter

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

diff --git a/src/backend/rewrite/rewriteHandler.c b/src/backend/rewrite/rewriteHandler.c
index 7c99290be4d2147ce65f8b1ac3ecf81c09fa1054..f98062668d6dcb28b2192dc590c5658c2d7fc396 100644 (file)
--- a/src/backend/rewrite/rewriteHandler.c
+++ b/src/backend/rewrite/rewriteHandler.c
@@ -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.