Re: 'update' as action of 'insert' rule: permission denied

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tim Burgess <tim(at)queens(dot)unimelb(dot)edu(dot)au>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: 'update' as action of 'insert' rule: permission denied
Date: 2003-02-13 21:42:33
Message-ID: 28483.1045172553@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-bugs

Tim Burgess <tim(at)queens(dot)unimelb(dot)edu(dot)au> writes:
> I'm surprised I can't find any descriptions of this in the archive
> already, since I had imagined it would be a common action, but
> apparently not!

I'm surprised too. This bug seems to have escaped notice for quite awhile.
Attached is the patch against 7.3 (it would probably work in 7.2 or
earlier too, but I didn't try it).

regards, tom lane

*** src/backend/rewrite/rewriteHandler.c.orig Thu Jan 16 21:01:16 2003
--- src/backend/rewrite/rewriteHandler.c Thu Feb 13 16:23:18 2003
***************
*** 62,70 ****
--- 62,72 ----
{
int current_varno,
new_varno;
+ List *main_rtable;
int rt_length;
Query *sub_action;
Query **sub_action_ptr;
+ List *rt;

/*
* Make modifiable copies of rule action and qual (what we're passed
***************
*** 99,114 ****
* Generate expanded rtable consisting of main parsetree's rtable plus
* rule action's rtable; this becomes the complete rtable for the rule
* action. Some of the entries may be unused after we finish
! * rewriting, but if we tried to clean those out we'd have a much
* harder job to adjust RT indexes in the query's Vars. It's OK to
* have unused RT entries, since planner will ignore them.
*
* NOTE: because planner will destructively alter rtable, we must ensure
* that rule action's rtable is separate and shares no substructure
* with the main rtable. Hence do a deep copy here.
*/
! sub_action->rtable = nconc((List *) copyObject(parsetree->rtable),
! sub_action->rtable);

/*
* Each rule action's jointree should be the main parsetree's jointree
--- 101,131 ----
* Generate expanded rtable consisting of main parsetree's rtable plus
* rule action's rtable; this becomes the complete rtable for the rule
* action. Some of the entries may be unused after we finish
! * rewriting, but if we tried to remove them we'd have a much
* harder job to adjust RT indexes in the query's Vars. It's OK to
* have unused RT entries, since planner will ignore them.
*
* NOTE: because planner will destructively alter rtable, we must ensure
* that rule action's rtable is separate and shares no substructure
* with the main rtable. Hence do a deep copy here.
+ *
+ * Also, we must disable write-access checking in all the RT entries
+ * copied from the main query. This is safe since in fact the rule action
+ * won't write on them, and it's necessary because the rule action may
+ * have a different commandType than the main query, causing
+ * ExecCheckRTEPerms() to make an inappropriate check. The read-access
+ * checks can be left enabled, although they're probably redundant.
*/
! main_rtable = (List *) copyObject(parsetree->rtable);
!
! foreach(rt, main_rtable)
! {
! RangeTblEntry *rte = (RangeTblEntry *) lfirst(rt);
!
! rte->checkForWrite = false;
! }
!
! sub_action->rtable = nconc(main_rtable, sub_action->rtable);

/*
* Each rule action's jointree should be the main parsetree's jointree

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Laurette Cisneros 2003-02-13 23:36:06 warnings in logs
Previous Message guillermo schulman 2003-02-13 21:09:08 backup/restore and vacuumdb

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2003-02-13 22:51:25 Re: Bug #896: Column Constraint Not Working in ALTER TABLE ADD COLUMN?
Previous Message Florian Wunderlich 2003-02-13 16:27:21 Re: Bug #866 related problem (ATTN Tom Lane)