Re: pgsql: RLS refactoring - Mailing list pgsql-committers

From Stephen Frost
Subject Re: pgsql: RLS refactoring
Date
Msg-id 20150915224851.GD3685@tamriel.snowman.net
Whole thread Raw
In response to Re: pgsql: RLS refactoring  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgsql: RLS refactoring  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Stephen Frost wrote:
> >> The WithCheckOption node which was changed doesn't ever end up in the
> >> catalog, I don't believe; certainly not in pg_policy which just stores
> >> the expressions which come from transformWhereClause, which haven't
> >> changed.
>
> > Uhm, so why is it in readfuncs.c?  If you create a view "WITH CHECK
> > OPTION", the pg_rewrite row says ":withCheckOptions <>".  Does that not
> > change with your commit?
>
> That field would always be NIL in a query produced by the parser;

Right.

> it's only ever filled by the rewriter.  But if this is documented
> anywhere, I couldn't find it, and the placement of the field in struct
> Query seems designed to be as confusing as possible about that.  I'd have
> put it down near the end myself, and certainly have documented that it is
> NOT the parse-time representation of a WITH CHECK OPTION clause.  For that
> matter I don't even find it to be named very well, because it's impossible
> to avoid that impression with the name as-is.  Perhaps something like
> insertedCheckClauses would have been better.

Agreed.  I will see about improving on that situation with at least
documentation changes.  If we want to remove it completely then we'd
need to bump catversion..  Not against doing that if we want to though.
Might be better that way.

Thanks!

Stephen

Attachment

pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: RLS refactoring
Next
From: Tom Lane
Date:
Subject: Re: pgsql: RLS refactoring