Re: Possible typo in create_policy.sgml

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, 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-06 23:21:39
Message-ID: CAM3SWZT5c_soTZ9NwRw-v8rstyYmD5z_6_YsinKy1waxy6LQ6Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2015-01-06 23:24:17 Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
Previous Message Andrew Dunstan 2015-01-06 23:15:21 Re: Add min and max execute statement time in pg_stat_statement