Re: Add support for restrictive RLS policies
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
Robert Haas <robertmhaas@gmail.com>, Thom Brown <thom@linux.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-09-08T21:21:25Z
Lists: pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes: > * Alvaro Herrera (alvherre@2ndquadrant.com) wrote: >> Can't you keep those words as Sconst or something (DefElems?) until the >> execution phase, so that they don't need to be keywords at all? > Seems like we could do that, though I'm not convinced that it really > gains us all that much. These are only unreserved keywords, of course, > so they don't impact users the way reserved keywords (of any kind) can. > While there may be some places where we use a string to represent a set > of defined options, I don't believe that's typical -1 for having to write them as string literals; but I think what Alvaro really means is to arrange for the words to just be identifiers in the grammar, which you strcmp against at execution. See for example reloption_list. (Whether you use DefElem as the internal representation is a minor detail, though it might help for making the parsetree copyObject-friendly.) vacuum_option_elem shows another way to avoid making a word into a keyword, although to me that one is more of an antipattern; it'd be better to leave the strcmp to execution, since there's so much other code that does things that way. regards, tom lane
Commits
-
Add support for restrictive RLS policies
- 093129c9d9fc 10.0 landed
-
Include <sys/select.h> where needed
- 51c3e9fade76 10.0 cited
-
Apply table and domain CHECK constraints in name order.
- e5f455f59fed 9.5.0 cited