Re: pgsql: RLS refactoring

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: pgsql: RLS refactoring
Дата
Msg-id 20150915224851.GD3685@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: pgsql: RLS refactoring  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pgsql: RLS refactoring  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-committers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Stephen Frost wrote:
> >> The WithCheckOption node which was changed doesn't ever end up in the
> >> catalog, I don't believe; certainly not in pg_policy which just stores
> >> the expressions which come from transformWhereClause, which haven't
> >> changed.
>
> > Uhm, so why is it in readfuncs.c?  If you create a view "WITH CHECK
> > OPTION", the pg_rewrite row says ":withCheckOptions <>".  Does that not
> > change with your commit?
>
> That field would always be NIL in a query produced by the parser;

Right.

> it's only ever filled by the rewriter.  But if this is documented
> anywhere, I couldn't find it, and the placement of the field in struct
> Query seems designed to be as confusing as possible about that.  I'd have
> put it down near the end myself, and certainly have documented that it is
> NOT the parse-time representation of a WITH CHECK OPTION clause.  For that
> matter I don't even find it to be named very well, because it's impossible
> to avoid that impression with the name as-is.  Perhaps something like
> insertedCheckClauses would have been better.

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.

Thanks!

Stephen

Вложения

В списке pgsql-committers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pgsql: RLS refactoring
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pgsql: RLS refactoring