* 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.
> 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...).
Thanks,
Stephen
signature.asc
Description: Digital signature
