Re: [PATCH] DefaultACLs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] DefaultACLs
Date
Msg-id 13288.1254166310@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] DefaultACLs  (Josh Berkus <josh@agliodbs.com>)
Responses Re: [PATCH] DefaultACLs
Re: [PATCH] DefaultACLs
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
>> This isn't just a matter of a few missed cases while coding, I think.
>> The generic issue that the code doesn't even think about addressing
>> is which default should apply when there's potentially more than one
>> applicable default?  

> I thought the idea was to simply avoid that situation.  Maybe we want to
> forget about global defaults if that's the case, and just do the ROLE
> defaults.

That seems like a pretty dead-end design.

> I thought we were trying to keep this solution as simple as possible.
> It's meant to be a simple feature for simple use cases.  I know we all
> love making stuff as ornate and complex as possible around here, but
> that kind of defeats the purpose of having DefaultACLs, as well as
> setting the bar unreasonably high for Petr.    Asking him to
> future-filter-proof the feature assumes that there will be future
> filters, which I'm not convinced there will.

I already mentioned one case that there's longstanding demand for, which
is to instantiate the correct permissions on new partition child tables.

But more generally, this is a fairly large and complicated patch in
comparison to the reward, if the intention is that it will never support
anything more than the one case of "IN SCHEMA foo" filtering.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: syslog_line_prefix
Next
From: Andrew Dunstan
Date:
Subject: Re: syslog_line_prefix