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

From Dean Rasheed
Subject Re: 9.2: Describing a security barrier view in psql
Date
Msg-id CAEZATCWQQtOSJ6H1CdT5tc+jCncgW=C2k+E7oMwTZ0JmBfHgKg@mail.gmail.com
Whole thread Raw
In response to Re: 9.2: Describing a security barrier view in psql  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 3 September 2012 14:48, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
>

Yes that makes sense. I was just going for the minimal quick fix.

Regards,
Dean



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pg_upgrade test mods for Windows/Mingw
Next
From: Tom Lane
Date:
Subject: Re: Yet another failure mode in pg_upgrade