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