Thread

1. 9.2: Describing a security barrier view in psql

   Dean Rasheed <dean.a.rasheed@gmail.com> — 2012-09-03T09:17:26Z

   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
   

2. Re: 9.2: Describing a security barrier view in psql

   Tom Lane <tgl@sss.pgh.pa.us> — 2012-09-03T13:48:01Z

   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
   
   
   

3. Re: 9.2: Describing a security barrier view in psql

   Magnus Hagander <magnus@hagander.net> — 2012-09-03T13:51:07Z

   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/
   
   
   

4. Re: 9.2: Describing a security barrier view in psql

   Dean Rasheed <dean.a.rasheed@gmail.com> — 2012-09-03T13:59:24Z

   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