Re: 9.2: Describing a security barrier view in psql - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 9.2: Describing a security barrier view in psql
Date
Msg-id 11855.1346680081@sss.pgh.pa.us
Whole thread Raw
In response to 9.2: Describing a security barrier view in psql  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: 9.2: Describing a security barrier view in psql  (Magnus Hagander <magnus@hagander.net>)
Re: 9.2: Describing a security barrier view in psql  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pg_upgrade test mods for Windows/Mingw
Next
From: Magnus Hagander
Date:
Subject: Re: 9.2: Describing a security barrier view in psql