Skip site navigation (1) Skip section navigation (2)

Re: [COMMITTERS] pgsql: Add a hook in ExecCheckRTPerms().

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Robert Haas <rhaas(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Add a hook in ExecCheckRTPerms().
Date: 2010-07-09 21:21:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-committerspgsql-hackers
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On Fri, 2010-07-09 at 14:01 -0400, Tom Lane wrote:
>> Consider PREPARE followed only later by EXECUTE.  Your proposal would
>> make the PREPARE fail outright, when it currently does not.

> Just to avoid wasted investigation: are you saying that is important
> behaviour that is essential we retain in PostgreSQL, or will you hear
> evidence that supporting that leads to a performance decrease elsewhere?

Well, I think that that problem makes moving the checks into the planner
a nonstarter.  But as somebody pointed out upthread, you could still get
what you want by keeping a flag saying "permission checks have been
done" so the executor could skip the checks on executions after the
first.  I'd still want to see some evidence showing that it's worth
troubling over though.  Premature optimization being the root of all
evil, and all that.  (In this case, the hazard we expose ourselves to
seems to be security holes due to missed resets of the flag.)

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2010-07-09 22:49:27
Subject: Re: Assertion failure in get_attstatsslot()
Previous:From: Robert HaasDate: 2010-07-09 20:53:56
Subject: Re: Reworks of DML permission checks

pgsql-committers by date

Next:From: Tom LaneDate: 2010-07-09 22:57:39
Subject: pgsql: Avoid an Assert failure in deconstruct_array() by making
Previous:From: Tom LaneDate: 2010-07-09 21:11:57
Subject: pgsql: Fix ruleutils' get_variable() to print something useful for Vars

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group