Re: pgsql: RLS refactoring - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql: RLS refactoring
Date
Msg-id 28196.1442358966@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql: RLS refactoring  (Stephen Frost <sfrost@snowman.net>)
Responses Re: pgsql: RLS refactoring  (Andres Freund <andres@anarazel.de>)
Re: pgsql: RLS refactoring  (Stephen Frost <sfrost@snowman.net>)
List pgsql-committers
Stephen Frost <sfrost@snowman.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


pgsql-committers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: pgsql: RLS refactoring
Next
From: Andres Freund
Date:
Subject: Re: pgsql: RLS refactoring