2011/10/8 Noah Misch <noah@leadboat.com>:
> On Sat, Oct 08, 2011 at 09:11:08AM +0200, Kohei KaiGai wrote:
>> 2011/10/8 Noah Misch <noah@leadboat.com>:
>> > On Sun, Oct 02, 2011 at 07:16:33PM +0200, Kohei KaiGai wrote:
>> >> My preference is still also WITH(security_barrier=...) syntax.
>> >>
>> >> The arguable point was the behavior when a view is replaced without
>> >> explicit WITH clause;
>> >> whether we should consider it was specified a default value, or we
>> >> should consider it means
>> >> the option is preserved.
>> >> If we stand on the viewpoint that object's attribute related to
>> >> security (such as ownership,
>> >> acl, label, ...) should be preserved, the security barrier also shall
>> >> be preserved.
>> >> On the other hand, we can never know what options will be added in the
>> >> future, right now.
>> >> Thus, we may need to sort out options related to security and not at
>> >> DefineVirtualRelation().
>> >>
>> >> However, do we need to limit type of the options to be preserved to
>> >> security related?
>> >> It is the first case that object with arbitrary options can be replaced.
>> >> It seems to me we have no matter, even if we determine object's
>> >> options are preserved
>> >> unless an explicit new value is provided.
>> >
>> > Currently, you can predict how CREATE OR REPLACE affects a given object
>> > characteristic with a simple rule: if the CREATE OR REPLACE statement can
>> > specify a characteristic, we don't preserve its existing value. ?Otherwise, we
>> > do preserve it. ?Let's not depart from that rule.
>> >
>> > Applying that rule to the proposed syntax, it shall not preserve the existing
>> > security_barrier value. ?I think that is acceptable. ?If it's not acceptable, we
>> > need a different syntax -- perhaps CREATE SECURITY VIEW.
>> >
>> No. It also preserves the security-barrier flag, when we replace a view without
>> SECURITY option. The only difference is that we have no way to turn off
>> security-barrier flag explicitly, right now.
>>
>> The major reason why I prefer reloptions rather than "SECURITY" option is
>> that allows to reuse the existing capability to store a property of relation.
>> It seems to me both of syntax enables to achieve the rule to preserve flags
>> when a view is replaced.
>
> Yes, there are no technical barriers to implementing either behavior with either
> syntax. However, CREATE OR REPLACE VIEW ... WITH (...) has a precedent guiding
> its behavior: if a CREATE OR REPLACE statement can specify a characteristic, we
> don't preserve its existing value.
>
I tried to refactor the patches based on the interface of WITH (...)
and usage of
pg_class.reloptions, although here is no functionality changes; including the
behavior when a view is replaced.
My preference is WITH (...) interface, however, it is not a strong one.
So, I hope either of versions being reviewed.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>