Re: Extension Templates S03E11 - Mailing list pgsql-hackers

On 13 December 2013 18:42, Stephen Frost <sfrost@snowman.net> wrote:
> * Jeff Davis (pgsql@j-davis.com) wrote:
>> For what it's worth, I think the idea of extension templates has good
>> conceptual integrity. Extensions are external blobs. To make them work
>> more smoothly in several ways, we move them into the catalog. They have
>> pretty much the same upsides and downsides of our existing extensions,
>> aside from issues directly related to filesystem vs. catalog.
>
> I've never particularly liked the idea that extensions are external
> blobs, to be honest.

I've been reading this, trying to catch back up with hackers. This
thread is amazing because this feature ought to be a shoe-in.

Jeff expresses his points politely, but not strongly enough. I agree with him.

I keep seeing people repeat "I don't like blobs" as if that were an
objection. There is no danger or damage from doing this. I can't see
any higher beauty that we're striving for by holding out. Why not
allow the user to choose XML, JSON, YAML, or whatever they choose.

Some things need to wait for the right design, like RLS, for a variety
of reasons. I don't see any comparison here and I can't see any reason
for a claim of veto on grounds of higher wisdom to apply to this case.

Blocking this stops nothing, it just forces people to do an extra
non-standard backflip to achieve their goals. Is that what we want?
Why?

>> Stephen had some legitimate concerns. I don't entirely agree, but they
>> are legitimate concerns, and we don't want to just override them.
>>
>> At the same time, I'm skeptical of the alternatives Stephen offered
>> (though I don't think he intended them as a full proposal).
>
> It was more thoughts on how I'd expect these things to work.  I've also
> been talking to David about what he'd like to see done with PGXN and his
> thinking was a way to automate creating RPMs and DEBs based on PGXN spec
> files, but he points out that the challenge there is dealing with
> external dependencies.
>
>> So right now I'm discouraged about the whole idea of installing
>> extensions using SQL. I don't see a lot of great options. On top of
>> that, the inability to handle native code limits the number of
>> extensions that could make use of such a facility, which dampens my
>> enthusiasm.
>
> Yeah, having looked at PGXN, it turns out that some 80+% of the
> extensions there have .c code included, something well beyond what I was
> expecting, but most of those cases also look to have external
> dependencies (eg: FDWs), which really makes me doubt this notion that
> they could be distributed independently and outside of the OS packaging
> system (or that it would be a particularly good idea to even try...).

That is clear evidence that the packaging is getting in the way of
extensions that don't include binary programs.

My only personal interest in this is to stimulate the writing of
further extensions, which is fairly clearly hampered by the overhead
required for packaging.

Who needs old fashioned package management? Some bigger extensions
need it. Smaller ones don't. Who are we to force people to distribute
their wares in only certain ways?

I can't see any reason to block this, nor any better design than the
flexible, neutral and simple one proposed. If there's some secret
reason to block this, please let me know off list cos I currently
don't get it at all.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services