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-07 20:09:56 |
Message-ID: | 20150107200956.GA3062@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Peter Geoghegan (pg(at)heroku(dot)com) wrote:
> I also don't see this behavior documented (this is from process_policies()):
>
> /*
> * If we end up with only USING quals, then use those as
> * WITH CHECK quals also.
> */
> if (with_check_quals == NIL)
> with_check_quals = copyObject(quals);
>
> Now, I do see a reference to it under "Per-Command policies - ALL". It says:
>
> "If an INSERT or UPDATE command attempts to add rows to the table
> which do not pass the ALL WITH CHECK (or USING, if no WITH CHECK
> expression is defined) expression, the command will error."
>
> 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.
Ah, yes, good point, I can add more documentation around that.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-01-07 20:17:06 | Re: INSERT ... ON CONFLICT UPDATE and RLS |
Previous Message | Robert Haas | 2015-01-07 20:08:34 | Re: Possible typo in create_policy.sgml |