2012/2/28 Tom Lane <t...@sss.pgh.pa.us>: > Christopher Browne <cbbro...@gmail.com> writes: >> On Mon, Feb 27, 2012 at 6:20 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> So, whatever the desirability of having them run as table owner, >>> we can't just up and change that. > >> I'm inclined to hold to the argument that it Works Properly Now, and >> that we shouldn't break it by changing it. > > I would say the same, or at least that any argument for changing it is > probably not strong enough to trump backwards compatibility. >
+1 > However, Peter seems to think the other way is required by standard. > We can get away with defining whatever behavior we want for triggers > that invoke functions, since that syntax is nonstandard anyway. But, > if you remember the original point of this thread, it was to add syntax > that is pretty nearly equivalent to the spec's. If we're going to do > that, it had better also have semantics similar to the spec's. > > So (assuming Peter has read the spec correctly) I'm coming around to the > idea that the anonymous trigger functions created by this syntax ought > to be "SECURITY DEFINER table_owner". > It should be strange if using two forms of one code can have two relative different behave. Actually we are in opposition to spec, because it expect SECURITY DEFINER for all stored procedures. All logic about rights are consistent now and I am not for changes in this area. Regards Pavel > regards, tom lane > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
