Re: Extension Templates S03E11

* Jeff Davis (pgsql(at)j-davis(dot)com) wrote:
> I understand there are reasons, but I'm having a hard time getting past
> the idea that "I have extension foo v1.2" now needs to be qualified with
> "installed using SQL" or "installed using the filesystem" to know what
> you actually have and how it will behave.

I can certainly understand that.

> Stepping back, maybe we need to do some more research on existing
> SQL-only extensions. We might be over-thinking this. How many extensions
> are really just a collection of functions on existing types? If you
> define a new data type, almost all of the functions seem to revolve
> around C code -- not just to define the basic data type, but also the
> GiST support routines, which then mean you're implementing operators in
> C too, etc.

Fair point- I'll try and find time to review the 100+ extensions on PGXN
and classify them (unless someone else would like to or happens to
already know..?). That said, there's certainly cases where people find
the existing extension system stinks for their SQL-only code and
therefore don't use it- which is exactly the case I'm in @work. We have
a ton of pl/pgsql code (along with schema definitions and the like), our
own build system which builds both 'full/new' databases based on a
certain version *and* will verify that newly built == current version
plus a hand-written update script (of course, we have to write that
update script) with versioned releases, etc.

Point simply being that, were extensions more generally useful, we might
see more of them and we need to consider more than just what's in PGXN,
and therefore already built as an extension, today.

> Perhaps we should first focus on making SQL-only extensions more useful?

I'm not following what you're suggesting here..? In general, I agree;
do you have specific ideas about how to do that? Ones which don't
involve a superuser or modifying the filesystem under PG, and which
works with replication and backups..?

Thanks,

Stephen