On 13 December 2013 18:42, Stephen Frost <sfr...@snowman.net> wrote: > * Jeff Davis (pg...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
