From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Possible typo in create_policy.sgml |
Date: | 2015-01-29 03:19:18 |
Message-ID: | 20150129031918.GH3854@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter,
* Peter Geoghegan (pg(at)heroku(dot)com) wrote:
> I also don't see this behavior documented (this is from process_policies()):
[...]
> But is that really the right place for it? Does it not equally well
> apply to FOR UPDATE policies, that can on their own have both barriers
> quals and WITH CHECK options? Basically, that seems to me like a
> *generic* property of policies (it's a generic thing that the WITH
> CHECK options/expressions "shadow" the USING security barrier quals as
> check options), and so should be documented as such.
Thanks, you're right, the documentation there can be improved. I've
pushed up a change to clarify that the USING quals will be used for the
WITH CHECK case if no WITH CHECK quals are specified. Hopefully that's
clear now, but please let me know if you feel further improvements to
this would help.
I do think we will be making additional changes in this area before too
long, but good to get it cleaned up now anyway, so we don't forget to
do so later.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Jerry Sievers | 2015-01-29 03:20:35 | Small bug on CREATE EXTENSION pgq... |
Previous Message | Robert Haas | 2015-01-29 02:59:41 | Re: Parallel Seq Scan |