KaiGai Kohei wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >> KaiGai Kohei <kaigai@ak.jp.nec.com> writes:
> >>> I'll try your approash in first, as follows:
> >> This seems a vast amount of uglification to avoid adding an argument to
> >> CreateTemplateTupleDesc. We do that kind of thing all the time --- it
> >> is a simple and reliable change to make.
> >>
> >> When designing a patch, you should generally try to make the code look
> >> like the patch has been there all along. Contorting logic to avoid
> >> a simple API change is not good.
> >
> > Just to chime in, I agree with Simon's direction of making the security
> > specification for the table match WITH OIDS, and agree with Tom that the
> > implementation should follow the WITH OIDS API for clarity, not trying
> > to reduce the change footprint. Basically, if WITH OIDS and security
> > definer behave the same in the API, there is little additional code
> > _complexity_, even if the patch is now larger.
>
> OK, I'll try to start implementing the feature again.
>
> However, the toggle of row-level security feature should be controled
> via a GUC option, not a discretionary option.
> I'll add a "sepostgresql_row_level" option defined as bool to control
> it on start up time.
This sounds similar to BSD capability were certain security settings can
only be changed in single-user mode.
> In addition, please do not stop reviewing the current patch set
> due to lack of the feature to disable row-level security.
Of course.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +