Robert Haas wrote: > On Wed, Aug 5, 2015 at 12:36 PM, Alvaro Herrera > <alvhe...@2ndquadrant.com> wrote: > > Bruce Momjian wrote: > >> I understand the desire for a diagnostic function in core, but we have > >> to be consistent. Just because we are adding this function now doesn't > >> mean we should use different rules from what we did previously for > >> diagnostic functions. Either their is logic to why this function is > >> different from the other diagnostic functions in contrib, or we need to > >> have a separate discussion of whether diagnostic functions belong in > >> contrib or core. > > > > Then let's start moving some extensions to src/extension/. > > That seems like yet another separate issue. > > FWIW, it seems to me that we've done a heck of a lot of moving stuff > out of contrib over the last few releases. A bunch of things moved to > src/test/modules and a bunch of things went to src/bin. We can move > more, of course, but this code reorganization has non-trivial costs > and I'm not clear what benefits we hope to realize and whether we are > in fact realizing those benefits. At this point, the overwhelming > majority of what's in contrib is extensions; we're not far from being > able to put the whole thing in src/extensions if it really needs to be > moved at all.
There are a number of things in contrib that are not extensions, and others are not core-quality yet. I don't think we should move everything; at least not everything in one go. I think there are a small number of diagnostic extensions that would be useful to have in core (pageinspect, pg_buffercache, pg_stat_statements). > But I don't think it's fair to conflate that with Bruce's question, > which it seems to me is both a fair question and a different one. Well, there was no question as such. If the question is "should we instead put it in contrib just to be consistent?" then I think the answer is no. I value consistency as much as every other person, but I there are other things I value more, such as availability. If stuff is in contrib and servers don't have it installed because of package policies and it takes three management layers' approval to get it installed in a dying server, then I prefer to have it in core. If the question was "why are we not using the rule we previously had that diagnostic tools were in contrib?" then I think the answer is that we have evolved and we now know better. We have evolved in the sense that we have more stuff in production now that needs better diagnostic tooling to be available; and we know better now in the sense that we have realized there's this company policy bureaucracy that things in contrib are not always available for reasons that are beyond us. Anyway, the patch as proposed puts the new functions in core as builtins (which is what Bruce seems to be objecting to). Maybe instead of proposing moving existing extensions in core, it would be better to have this patch put those two new functions alone as a single new extension in src/extension, and not move anything else. I don't necessarily resist adding these functions as builtins, but if we do that then there's no going back to having them as an extension instead, which is presumably more in line with what we want in the long run. (It would be a shame to delay this patch, which messes with complex innards, just because of a discussion about the placement of two smallish diagnostic functions.) -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
