Re: [PATCH] DefaultACLs
От | Josh Berkus |
---|---|
Тема | Re: [PATCH] DefaultACLs |
Дата | |
Msg-id | 4AC10BB8.4030705@agliodbs.com обсуждение исходный текст |
Ответ на | Re: [PATCH] DefaultACLs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCH] DefaultACLs
|
Список | pgsql-hackers |
> There is another large problem, too. The patch seems to have > only half-baked support for global defaults (those not tied to a > specific schema) --- it looks like you can put them in, but half > of the code will ignore them or else fail while trying to use them. > 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. 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 certainly haven't seen any good use case for having multiple conflicting defaults. In fact, I thought we'd agreed that any complex cases would be better handled by PL scripts. pg_dump support is required though. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com
В списке pgsql-hackers по дате отправления: