Re: pgsql: RLS refactoring

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pgsql: RLS refactoring
Дата
Msg-id 28196.1442358966@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pgsql: RLS refactoring  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: pgsql: RLS refactoring  (Andres Freund <andres@anarazel.de>)
Re: pgsql: RLS refactoring  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: pgsql: RLS refactoring
Следующее
От: Andres Freund
Дата:
Сообщение: Re: pgsql: RLS refactoring