KaiGai Kohei wrote: > Bruce Momjian wrote: > > Tom Lane wrote: > >> KaiGai Kohei <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
