Re: row_security GUC does not behave as documented

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: row_security GUC does not behave as documented
Date: 2016-01-04 04:04:08
Message-ID: 28523.1451880248@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> As we don't want to end up with the same behavior-change-due-to-GUC that
> we had with the original row_security implementation, we should change
> the code as your patch does and update the regression tests accordingly.

I think probably the tests need some adjustment rather than just stuffing
in the new results; but I'm unsure what's most appropriate.

> Perhaps the error code thrown could be tailored a bit when it's the
> owner, to indicate that FORCE RLS has been set on the table, but I'm not
> sure it's really a big deal either way.

Yeah, the error message seemed less than apropos to me too; but on the
other hand there's an argument that FORCE RLS means "treat me just like
everybody else".

One idea would be to use the same primary error message either way,
but add a DETAIL or HINT mentioning FORCE RLS if it's the table owner.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2016-01-04 04:05:44 Re: row_security GUC does not behave as documented
Previous Message Stephen Frost 2016-01-04 03:56:49 Re: row_security GUC does not behave as documented