Re: 9.2: Describing a security barrier view in psql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 9.2: Describing a security barrier view in psql
Date: 2012-09-03 13:48:01
Message-ID: 11855.1346680081@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2012-09-03 13:51:07 Re: 9.2: Describing a security barrier view in psql
Previous Message Andrew Dunstan 2012-09-03 13:16:45 Re: pg_upgrade test mods for Windows/Mingw