Re: 9.2: Describing a security barrier view in psql

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: 9.2: Describing a security barrier view in psql
Дата
Msg-id 11855.1346680081@sss.pgh.pa.us
обсуждение исходный текст
Ответ на 9.2: Describing a security barrier view in psql  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Ответы Re: 9.2: Describing a security barrier view in psql
Re: 9.2: Describing a security barrier view in psql
Список pgsql-hackers
Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> Unless I'm missing something, it is not possible in psql to tell
> whether a view has the security_barrier option. I think that this is
> something that ought to be possible from psql, otherwise the new
> feature is not visible.

> This patch displays any reloptions for a view at the end, if \d+ is
> used, in the same way as for tables.

> Sorry if this is too late for 9.2. I really only just noticed this,
> despite playing with security barrier views for a while.

Seems to me we should include this into 9.2, since the security_barrier
feature exists there.  It's not quite too late.  Any objections?

I'd be inclined to go about it a bit differently though: rather than
duplicating the code, in a way that's *still* wrong the next time we
enable reloptions for a new relkind, I think we should just pull the
reloptions-printing code block out of where it is and print reloptions
regardless of relkind, if verbose and there are some.  This would have
the effect of switching the order of the tablespace and reloptions
footers when both are present, but that doesn't bother me any - the
existing order is only a historical artifact anyway AFAIK.
        regards, tom lane



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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: pg_upgrade test mods for Windows/Mingw
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: 9.2: Describing a security barrier view in psql