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
Attachments:
describe-view-options.patchapplication/octet-stream; name=describe-view-options.patchDownload
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
new file mode 100644
index c2bcc5a..6e40199
*** a/src/bin/psql/describe.c
--- b/src/bin/psql/describe.c
*************** describeOneTableDetails(const char *sche
*** 2250,2255 ****
--- 2250,2270 ----
true);
}
+ /*
+ * Print any view options.
+ */
+ if (tableinfo.relkind == 'v' && verbose)
+ {
+ if (tableinfo.reloptions && tableinfo.reloptions[0] != '\0')
+ {
+ const char *t = _("Options");
+
+ printfPQExpBuffer(&buf, "%s: %s", t,
+ tableinfo.reloptions);
+ printTableAddFooter(&cont, buf.data);
+ }
+ }
+
printTable(&cont, pset.queryFout, pset.logfile);
printTableCleanup(&cont);
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 Hagander
Me: 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