Robert,
* Robert Haas (robertmhaas@gmail.com) wrote:
> On Fri, Jan 23, 2015 at 1:16 PM, Stephen Frost <sfrost@snowman.net> wrote:
> >> Well, I'm still of the view that there's little to lose by having this
> >> remain out-of-core for a release or three. We don't really all agree
> >> on what we want, and non-core code can evolve a lot faster than core
> >> code, so what's the rush?
> >
> > Being out of core makes it unusable in production environments for a
> > large number of organizations. :/
>
> Tough. Once we accept something into core, we're stuck maintaining it
> forever. We shouldn't do that unless we're absolutely confident the
> design is solid. We are not close to having consensus on this. If
> somebody has a reason for accepting only core PostgreSQL and not
> add-ons, it's either a stupid reason, or it's because they believe
> that the core stuff will be better thought-out than the add-ons. If
> it's the latter, we shouldn't disappoint.
I don't disagree with you about any of that. I don't think you disagree
with my comment either. What I'm not entirely clear on is how consensus
could be reached. Leaving it dormant for the better part of a year
certainly doesn't appear to have helped that situation. We've discussed
having it be part of the main server and having it be a contrib module
and until about a week ago, I had understood that having it in contrib
would be preferrable. Based on the recent emails, it appears there's
been a shift of preference to having it be in-core, but clearly there's
no time left to do that in this release cycle.
While I appreciate that it doesn't quite feel right to use the GRANT
system in the way I'm suggesting, I'm of the opinion that it's mostly
due to a lack of implementation with documentation and examples about
how it would work. Using the GRANT system gives us nearly the best of
both worlds- an SQL-based syntax, a very fine-grained configuration
method, dependency handling, rename handling, and means you don't need
to be a superuser or have to restart the server to change the config,
nor is there any need to deal with CSV configuration via GUCs.
For my part, I'd still prefer an in-core system with top-level syntax
(eg: AUDIT), but that could clearly come later even if we included
pgaudit today (as Tom and others pointed out to me early this past
summer). Auditing should definitely be a top-level capability in PG and
shouldn't be relegated to external modules or commercial solutions.
I've come around to feel that perhaps the first step should be a contrib
module rather than going in-core from the beginning as we'd get the
feedback which could lead to a better in-core solution. I don't think
we're going to get it perfectly right the first time, either way, and
having it be completely outside the tree will mean we won't get any real
feedback on it.
Thanks,
Stephen
