Re: Possible typo in create_policy.sgml

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

In response to

Browse pgsql-hackers by date

  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