* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote: > Stephen Frost <sfr...@snowman.net> writes: > >> My thinking is that if we invent a new mechanism for extensions that are > >> not managed like contribs, we will find out that only contribs are going > >> to be using extensions. > > > > That's only accurate if the new mechanism supports .so's, which seems > > unlikely to be the case. > > Really?
Yes. The 'new mechanism' to which I was referring was when the entire
XXX (extension, library, package, whatever) is in the PG catalog and not
managed through files on the filesystem, as contrib-like extensions are.
I'm quite aware that what you're asking for is technically possible-
that's not what this discussion is about.
> The only reason why the current proposal mention *nothing* about how to
> deal with modules (.so etc) is because each and every time a mention is
> made about that problem, the answer from Tom is “rejected, full stop”.
Perhaps I'm not making myself clear here, but *I agree with Tom* on this
point.
> > There would also be flexability in that an author might choose to use an
> > extension even in cases where it's not strictly necessary to do so, for
> > whatever reason they want.
>
> Note that of course you can still install proper OS packages when we
> ship with support for Extension Templates.
With the various naming conflicts and other risks associated with doing
that, which I don't believe were very clearly addressed. An
off-the-cuff answer to that issue is not sufficient, imv.
> You still didn't propose any other way to have at it, where it's already
> my fourth detailed proposal.
I didn't outline a proposal which provides what you want, no. That was
intentional.
> I did spend time on designing what I think
> you're trying to say hand-wavely in that exchange, and I don't quite
> like the result, as I see now way for it not to entirely deprecate
> extensions.
I don't think we need to, nor should we, deprecate extensions entirely
when that's the approach which *should be* used for .so requiring
extensions. Obviously, that's my opinion, and you don't agree with it,
and it seems neither of us is willing to shift from that position.
> Maybe the proper answer is that we should actually confine extensions to
> being the way to install contribs and nothing else, and deprecate them
> for cases where you don't have an OS level package. It seems really
> strange to build a facility with such a generic name as “extension” only
> to resist changing any of it, then stop using it at first opportunity.
I'm open to changing how extensions work, to adding dependency
information and making other improvements. Being interested in
improving the extension system doesn't mean I'm required to support
shipping .so's in this manner or installing text script blobs into
catalog tables.
> > However, as I understand it from the various discussions on this topic
> > outside of this list, the immediate concern is the need for a multi-OS
> > extension distribution network with support for binaries, .so's and
> > .dll's and whatever else, to make installing extensions easier for
> > developers on various platforms. I'm all for someone building that and
> > dealing with the issues associated with that, but building a client for
> > it in core, either in a way where a backend would reach out and
> > download the files or accepting binary .so's through the frontend
> > protocol, isn't the first step in that and I very much doubt it would
> > ever make sense.
>
> That's exactly the reason why the first piece of that proposal has
> absolutely nothing to do with building said client, and is all about how
> NOT to have to build it in core *ever*.
You can already build what you're after without extension templates
entirely, if you're allowing files to be stashed out on the filesystem
anywhere. Your argument that you need root doesn't hold any water with
me on this issue- there's quite a few mechanisms out there already which
allow you to trivially become root. You can write pl/perlu which sudo's
and apt-get installs your favorite extension, if you like. That doesn't
mean we should build a system into core which tries to do that for you.
And, yes, I know that you pushed for and got the GUC in to allow you to
have other places to pull .so's from. Having that flexibility doesn't
mean we have to support populating that directory from PG. You probably
would have been better off pushing for a GUC that allowed a '.d' like
directory system for extensions to be defined in. That *still* doesn't
require extension templates, storing SQL scripts as text blobs in
catalog tables, and you can even avoid the whole 'root' concern if you
want.
> If you don't like what I'm building because it's not solving the problem
> you want to solve… well don't use what I'm building, right?
I'm pretty sure that I've pointed out a number of issues that go well
beyond not liking it.
Thanks,
Stephen
signature.asc
Description: Digital signature
