Date: Thu, 1 Dec 2016 10:09:27 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
	Jeevan Chalke <jeevan.chalke@enterprisedb.com>,
	Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	Thom Brown <thom@linux.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Add support for restrictive RLS policies
Message-ID: <20161201150927.GJ13284@tamriel.snowman.net>
References: 
 <CAM2+6=WaYrso+K4spreugPBxmBGNSwycXaS1B2a-dPieawJLwQ@mail.gmail.com>
 <CAM2+6=UHCuD_wT2kK_H2zL_9k8XabVLxOUaBgWcWqsSvBP1gXg@mail.gmail.com>
 <20160926204331.GA178854@alvherre.pgsql>
 <20160926195554.GA176476@alvherre.pgsql>
 <20160928191746.GZ5148@tamriel.snowman.net>
 <20161130215419.GZ13284@tamriel.snowman.net>
 <CAEZATCURYzb8M_DMsmKQ9LQ+rZUmM=3irATtLgkRxopw=j=yjg@mail.gmail.com>
 <20161201143857.GH13284@tamriel.snowman.net>
 <CAEZATCWMD2gaJCzLtxu0v79JCvJL4cUjbNMENjLTrBP07zz_fw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="2qkyu1R6kqeK19z+"
Content-Disposition: inline
In-Reply-To: 
 <CAEZATCWMD2gaJCzLtxu0v79JCvJL4cUjbNMENjLTrBP07zz_fw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--2qkyu1R6kqeK19z+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Dean,

* Dean Rasheed (dean.a.rasheed@gmail.com) wrote:
> On 1 December 2016 at 14:38, Stephen Frost <sfrost@snowman.net> wrote:
> > * Dean Rasheed (dean.a.rasheed@gmail.com) wrote:
> >> In get_policies_for_relation() ...
> >> ... I think it should sort the restrictive policies by name
> >
> > Hmmm, is it really the case that the quals will always end up being
> > evaluated in that order though?  Isn't order_qual_clauses() going to end
> > up changing the order based on the relative cost?  If the cost is the
> > same it should maintain the order, but even that could change in the
> > future based on the comments, no?  In short, I'm not entirely sure that
> > we actually want to be required to always evaluate the quals in order of
> > policy name and we might get complaints if we happen to make that work
> > today and it ends up being changed later.
>=20
> No, this isn't about the quals that get put into the WHERE clause of
> the resulting queries. As you say, order_quals_clauses() is going to
> re-order those anyway. This is about the WithCheckOption's that get
> generated for UPDATEs and INSERTs, and having those checked in a
> predictable order. The main advantage to that is to guarantee a
> predictable error message from self tests that attempt to insert
> invalid data. This is basically the same as what was done for CHECK
> constraints in e5f455f59fed0632371cddacddd79895b148dc07.

You know, you said that in your email, and I read it and it made sense
to me, and then I went off to do something else and came back and
completely forgot that you were referring to the WITH CHECK case.

You're right, we should order the WithCheckOptions.  I'll update the
patch accordingly.

Thanks!

Stephen

--2qkyu1R6kqeK19z+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJYQD0nAAoJEO1sijiDR2RV1wIP/2N3GHGEgEML6Kii5nsorXSt
hVPbKB6uGrBRbDA57yVxMNfbrXdzXEa0UaXshXNSUv/1nzYwE6TFRrSHDlKILUNy
Dmnkj9K4Y9m1X7MWO7iureTQWVYea5XbK5QpLZ36KYIf0bv5V3GX/nBMd7wDCQuV
pp5PTZiLB9HNMOwWEbWCzg8OksVhP2HVKIDJgGbmPEanCFHgarnSwe4jE4waqvcT
ZadaKal5oKFotJifg5AdFKyH6hCp4lhDywfgYOko0u7oq/z7pjEd0jmb6oJKX/SR
NjBkh1vqbna+l5oCxNiDF98qjKSzkux7GqvhEHGHbzmwMH0xM6cjLMvyAaByDdv1
6Fn1Qalb705k6D0rMU30WnqBCKgxXKn644QR6TXy27rtRkU97QNZzjkS02hctS0F
tzjlJmVmpsfT9MxLPYLUL3ZwHNUH73OOIqXQnLKkgf66Huo0IAurmdptlchkxwfw
OStvob5DhWZW3+4D0fLuhmKuhYc83DC4a4SwkmC7a4hGS2klLWYHLRmLBUELmhte
PT5ngRq6o/+lx6eIuxD4fvu0WijWx9NB3MexOLu8knpV50VXZwwPrjbJRs0GC7Rq
chyBLPOEamyOVbu8tmdkdxaGKHjZ3vnZxyjapqtEB4nI+Kiumvi4GhkwU8EpnFwn
GLHzodLKOAyyfZVNBwTm
=VARE
-----END PGP SIGNATURE-----

--2qkyu1R6kqeK19z+--