Hi,
On 2/15/22 09:37, walther@technowledgy.de wrote:
> Christoph Heiss:
>>> xxx_owner=true would be the default and xxx_owner=false could be set
>>> explicitly to get the behavior we are looking for in this patch?
>>
>> I'm not sure if an option which is on by default would be best, IMHO.
>> I would rather have an off-by-default option, so that you explicitly
>> have to turn *on* that behavior rather than turning *off* the current.
>
> Just out of curiosity I asked myself whether there were any other
> boolean options that default to true in postgres - and there are plenty.
> ./configure options, client connection settings, server config options,
> etc - but also some SQL statements:
> - CREATE USER defaults to LOGIN
> - CREATE ROLE defaults to INHERIT
> - CREATE COLLATION defaults to DETERMINISTIC=true
>
> There's even reloptions, that do, e.g. vacuum_truncate.
Knowing that I happily drop my objection about that. :^)
> [..] The more I think about it, the more it becomes clear that
> really the current default behavior of "running the query as the view
> owner" is the special thing here, not the behavior you are introducing.
>
> If we were to start from scratch, it would be pretty obvious - to me -
> that run_as_owner=false would be the default, and the run_as_owner=true
> would need to be turned on explicitly. I'm thinking about "run_as_owner"
> as the better design and "defaults to true" as a backwards compatibility
> thing.
Right, if we treat that as a kind of "backwards-compatible" feature,
having an reloption that is on by default makes sense.
I converted the option to run_as_owner=true|false in the attached v7.
It now definitely seems like the right way to move forward and getting
more feedback.
Thanks,
Christoph Heiss
