From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] DefaultACLs |
Date: | 2009-09-28 19:31:50 |
Message-ID: | 13288.1254166310@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2009-09-28 19:43:29 | Re: syslog_line_prefix |
Previous Message | Alvaro Herrera | 2009-09-28 19:27:33 | Re: syslog_line_prefix |