> 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
