On Mon, Mar 18, 2024 at 4:07 PM Robert Treat <rob@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
