Josh Berkus <josh@agliodbs.com> writes:
> So, the reason I was confused by this feature -- and the reason Stephen
> hates it, I think -- is that I thought it was solving the "Extensions
> don't follow replication, and they are complicated to install if your OS
> doesn't have good packages" problem. It's not, and it never will solve
> that issue.
> It's solving a completely different problem, to wit:
> Some PostgreSQL shops with lots of servers have large internal libraries
> of functions, views, and similar code that they've written to support
> their applications, which don't comprise a complete database. This
> feature would allow them to "package" those libraries, and version,
> upgrade and track them, without requiring a filesystem-based install. I
> myself have a couple clients who could benefit from this.
Right. I think a lot of the tension comes from people being unconvinced
that the existing extension feature is an ideal model for this sort of
use-case. Extensions were mainly designed around the notion of a .so
with some SQL datatype/function/etc declarations that have to match up
with the C code. So it made sense for them to be relatively static things
that live in the filesystem. Notably, if you're migrating to a new PG
major version, you're at the very least gonna have to recompile the C code
and quite likely will need to change it some. So adapting the SQL code
if needed goes along with that, and would never be automatic in any case.
OTOH, for a set of pure-SQL objects, it's not necessary that there be a
canonical text file somewhere, and we have in principle complete knowledge
of the objects' semantics as well as the ability to dump-and-restore into
newer PG versions. So it's not at all clear that we should just adopt the
existing model with the smallest possible changes --- which AFAICS is
basically what this proposal is. Maybe that's the way to go, but we
should consider alternatives, and in particular I think there is much
more reason to allow inside-the-database mutation of the SQL objects.
> I think the name "Extension Templates" is horrible because it misleads
> all of us on this list into thinking the proposed feature is completely
> something other than what it is. I don't have a better name offhand,
> but that's got to change before it becomes a feature.
Given your previous para, I wonder if "library" or "package" would work
better. I agree that "template" isn't le mot juste.
regards, tom lane
