Re: pgsql: RLS refactoring

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: RLS refactoring
Date: 2015-09-15 23:16:06
Message-ID: 28196.1442358966@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> Agreed. I will see about improving on that situation with at least
> documentation changes. If we want to remove it completely then we'd
> need to bump catversion.. Not against doing that if we want to though.
> Might be better that way.

readfuncs.c doesn't actually stop to verify that the field name in stored
rules is what it expects. So I believe (but you'd better check) that
renaming the field could be done without initdb. If we wanted to change
its placement, we'd need initdb --- unless we wanted to move it in the
struct definition but not in _outQuery/_readQuery, which I wouldn't do
in HEAD but it might be acceptable in back branches.

So the limiting factor here is not initdb but avoiding an API/ABI break
for extensions that look at struct Query. It's clearly too late to do any
such thing in 9.4, but we still could accept API breaks for 9.5 I think.

My vote would be to rename and reposition the field in HEAD and 9.5
and accept the corresponding initdb. We already forced an initdb
since alpha2, so it's basically free as far as testers are concerned,
and keeping 9.5 in sync with HEAD in this area seems like a really
good idea for awhile to come.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Andres Freund 2015-09-15 23:44:31 Re: pgsql: RLS refactoring
Previous Message Stephen Frost 2015-09-15 22:48:52 Re: pgsql: RLS refactoring

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-09-15 23:44:31 Re: pgsql: RLS refactoring
Previous Message David Rowley 2015-09-15 22:50:39 Re: [PROPOSAL] Covering + unique indexes.