On Mon, Mar 18, 2024 at 4:07 PM Robert Treat <r...@xzilla.net> wrote: > You know it's funny, you say #4 has no advantage and should be > rejected outright, but AFAICT > > a) no one has actually laid out why it wouldn't work for them, > b) and it's the one solution that can be implemented now > c) and that implementation would be backwards compatible with some set > of existing releases > d) and certainly anyone running k8s or config management system would > have the ability to install > e) and it could be custom tailored to individual deployments as needed > (including other potential commands that some systems might care > about) > f) and it seems like the least likely option to be mistaken for a > security feature > g) and also seems pretty safe wrt not breaking existing tooling (like > 5/6 might do) > > Looking at it, you could make the argument that #4 is actually the > best of the solutions proposed, except it has the one drawback that it > requires folks to double down on the fiction that we think extensions > are a good way to build solutions when really everyone just wants to > have everything in core.
I think that all of this is true except for (c). I think we'd need a new hook to make it work. That said, I think that extensions are a good way of implementing some functionality, but not this functionality. Extensions are a good approach when there's a bunch of stuff core can't know but an extension author can. For instance, the FDW interface caters to situations where the extension author knows how to access some data that PostgreSQL doesn't know how to access; and the operator class stuff is useful when the extension author knows how some user-defined data type should behave and we don't. But there's not really a substantial policy question here. All we do by pushing a feature like this out of core is wash our hands of it. Your (f) argues that might be a good thing, but I don't think so. When we know that a feature is widely-needed, it's better to have one good implementation of it in core than several perhaps not-so-good implementations out of core. That allows us to focus all of our efforts on that one implementation instead of splitting them across several -- which is the whole selling point of open source, really -- and it makes it easier for users who want the feature to get access to it. -- Robert Haas EDB: http://www.enterprisedb.com
