database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-04 20:11:56 +03:00
Code Activity

Allow examine_simple_variable() to work on INSERT RETURNING Vars.

Browse Source 
Since commit 599b33b94, this function assumed that every RTE_RELATION
RangeTblEntry would have an associated RelOptInfo.  But that's not so:
we only build RelOptInfos for relations that are scanned by the query.
In particular the target of an INSERT won't have one, so that Vars
appearing in an INSERT ... RETURNING list will not have an associated
RelOptInfo.  This apparently wasn't a problem before commit f7816aec2
taught examine_simple_variable() to drill down into CTEs containing
INSERT RETURNING, but it is now.

To fix, add a fallback code path that gets the userid to use directly
from the RTEPermissionInfo associated with the RTE.  (Sadly, we must
have two code paths, because not every RTE has a RTEPermissionInfo
either.)

Per report from Alexander Lakhin.  No back-patch, since the case is
apparently unreachable before f7816aec2.

Discussion: https://postgr.es/m/608a4886-6c60-0f9e-97d5-591256bd4150@gmail.com
This commit is contained in:
Tom Lane
2024-01-08 11:48:44 -05:00
parent bea18b1c94
commit 89b69db82a
5 changed files with 56 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
src/backend/utils/adt/selfuncs.c
View File

@@ -119,6 +119,7 @@
#include "optimizer/paths.h"
#include "optimizer/plancat.h"
#include "parser/parse_clause.h"
#include "parser/parse_relation.h"
#include "parser/parsetree.h"
#include "statistics/statistics.h"
#include "storage/bufmgr.h"
@@ -5434,17 +5435,30 @@ examine_simple_variable(PlannerInfo *root, Var *var,
if (HeapTupleIsValid(vardata->statsTuple))
{
RelOptInfo *onerel = find_base_rel(root, var->varno);
RelOptInfo *onerel = find_base_rel_noerr(root, var->varno);
Oid userid;
/*
* Check if user has permission to read this column. We require
* all rows to be accessible, so there must be no securityQuals
* from security barrier views or RLS policies. Use
* onerel->userid if it's set, in case we're accessing the table
* via a view.
* from security barrier views or RLS policies.
*
* Normally the Var will have an associated RelOptInfo from which
* we can find out which userid to do the check as; but it might
* not if it's a RETURNING Var for an INSERT target relation. In
* that case use the RTEPermissionInfo associated with the RTE.
*/
userid = OidIsValid(onerel->userid) ? onerel->userid : GetUserId();
if (onerel)
userid = onerel->userid;
else
{
RTEPermissionInfo *perminfo;
perminfo = getRTEPermissionInfo(root->parse->rteperminfos, rte);
userid = perminfo->checkAsUser;
}
if (!OidIsValid(userid))
userid = GetUserId();
vardata->acl_ok =
rte->securityQuals == NIL &&