pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Stephen Frost <sfrost@snowman.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Thom Brown <thom@linux.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Add support for restrictive RLS policies
Date: Sun, 11 Sep 2016 21:57:48 -0400
Message-ID: <20160912015748.GF11453@tamriel.snowman.net> (raw)
In-Reply-To: <CA+Tgmoaf9A5dS7rdoxsyQe6=rxH=nNSV1pfcz-gRd_p8cSiOZQ@mail.gmail.com>
References: <20160908183544.GU4028@tamriel.snowman.net>
	<20160908192157.GA53172@alvherre.pgsql>
	<20160908200912.GW4028@tamriel.snowman.net>
	<5611.1473369685@sss.pgh.pa.us>
	<CA+Tgmoaf9A5dS7rdoxsyQe6=rxH=nNSV1pfcz-gRd_p8cSiOZQ@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

Robert,

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Thu, Sep 8, 2016 at 5:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > 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.
> 
> There are other cases like that, too, e.g. AlterOptRoleElem; I don't
> think it's a bad pattern.  Regardless of the specifics, I do think
> that it would be better not to bloat the keyword table with things
> that don't really need to be keywords.

The AlterOptRoleElem case is, I believe, what Tom was just suggesting as
an antipattern, since the strcmp() is being done at parse time instead
of at execution time.

If we are concerned about having too many unreserved keywords, then I
agree that AlterOptRoleElem is a good candidate to look at for reducing
the number we have, as it appears to contain 3 keywords which are not
used anywhere else (and 1 other which is only used in one other place).

I do think that using IDENT for the various role attributes does make
sense, to be clear, as there are quite a few of them, they change
depending on major version, and those keywords are very unlikely to ever
have utilization elsewhere.

For this case, there's just 2 keywords which seem like they may be used
again (perhaps for ALTER or DROP POLICY, or default policies if we grow
those in the future), and we're unlikly to grow more in the future for
that particular case (as we only have two binary boolean operators and
that seems unlikely to change), though, should that happens, we could
certainly revisit this.

Thanks!

Stephen

Attachments:

  [application/pgp-signature] signature.asc (818B, ../20160912015748.GF11453@tamriel.snowman.net/2-signature.asc)
  download

view thread (35+ messages)  latest in thread

Message-ID: <20160912015748.GF11453@tamriel.snowman.net>
Permalink:  ../20160912015748.GF11453@tamriel.snowman.net/
Also on:    postgresql.org/message-id/20160912015748.GF11453@tamriel.snowman.net

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: sfrost@snowman.net, robertmhaas@gmail.com, tgl@sss.pgh.pa.us, alvherre@2ndquadrant.com, thom@linux.com
  Subject: Re: Add support for restrictive RLS policies
  In-Reply-To: <20160912015748.GF11453@tamriel.snowman.net>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox