Re: Extension Templates S03E11

Stephen Frost <sfrost@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?

Look at dynamic_library_path, then at a classic CREATE FUNCTION command
that maps into a C provided symbol:
 CREATE OR REPLACE FUNCTION prefix_range_in(cstring) RETURNS prefix_range AS '$libdir/prefix' LANGUAGE C IMMUTABLE
STRICT;

A packaging or distribution software will have no problem removing the
'$libdir/' part of the magic AS string here. Once removed, prefix.so
will be loaded from anywhere on the file system paths listed into the
dynamic_library_path GUC.

So now, you don't need anymore to have file system write privileges into
a central place owned by root, it can be anywhere else, and the backend
hooks, when properly setup, will be able to benefit from that.

The missing bits are where to find the extension control files and
scripts.

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”.

> What I think we'd end up with is a split
> between extensions, which would be things containing .so's, and
> "libraries" or what-have-you, which would be more-or-less everything
> else.  That kind of a break-down strikes me as perfectly reasonable.

Only if it's the best we can do.

> 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.

> I'd like to see extensions improved.  I don't feel like the proposed
> 'extension templates' is the way to do that because I don't think it
> really solves anything and it adds a layer that strikes me as wholly
> unnecessary.

You still didn't propose any other way to have at it, where it's already
my fourth detailed proposal. 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.

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.

Also, I'm not sure about the consequences in terms of user trust if we
build something new to solve a use case that looks so much the same.

> 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*.

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?

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support