Re: Extension Templates S03E11

On 12/03/2013 09:25 AM, Jeff Davis wrote:
> On Mon, 2013-12-02 at 11:07 +0200, Heikki Linnakangas wrote:
>> There should be no difference between file-based extensions and
>> catalog-based extensions. It's just two different ways to install the
>> same extension. The extension author doesn't need to care about that,
>> it's the DBA that decides which method to use to install it.
>>
>> I'm going to object loudly to any proposal that doesn't meet that criteria.
>
> But we're arguably already in this position today. For a SQL-only
> extension, the author can choose between:
>
> 1. Using a schema/namespace
> a. installable over libpq
> b. installable by non-superusers
> c. no special handling when it comes to administration
>
> 2. Using an extension
> a. convenient metadata (e.g. "requires")
> b. upgrade scripts
> c. omitted from pg_dump so can be managed separately
> d. relocatable
> e. not tied to one schema
>
> And if the author decides to change, it requires porting the extension
> to the other form.
>
> Note: I'm using "extension" loosely here. We might call the SQL-only,
> user-installable variety something else.

Good point. It's not too hard to install an "extension" written as an
extension as plain schema objects, though. You can just run the .sql
script through psql. That's what you used to do before extensions were
invented. (the scripts in contrib contain an explicit check against
that, but I don't think that's common outside contrib)

Another perspective is that that's already a situation we'd rather not
have. Let's not make it worse by introducing a third way to install an
extension, which again requires the extension author to package the
extension differently.

> So how do we get to the point where we have clear advice to the author
> of a SQL-only extension? And how do we do that without asking them to
> port anything?

Yeah, that's the crucial question of this whole thread.

> Stephen mentioned using external tools and/or metadata, but to me that
> sounds like it would require porting the extension away from what's on
> PGXN today.

Why? The external tool can pick the extension in its current form from
PGXN, and install it via libpq. The tool might have to jump through some
hoops to do it, and we might need some new backend functionality to
support it, but I don't see why the extension author needs to do anything.

That said, it might make the tool easier to write if we place some new
requirements for extension authors. Like, stipulate that the .sql file
is in the top-level directory of the extension tarball. But the same
extension would still be installable with "make; make install".

- Heikki