Thread: 9.2: Describing a security barrier view in psql
Hi, 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. Regards, Dean
Attachment
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
On Mon, Sep 3, 2012 at 3:48 PM, 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? +1, I was about to suggest that myself. Haven't reviewed the code, I'm talking about the principle. I think it can almost be considered a bugfix for the security_barrier feature. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
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