Re: Extensions, patch v19 (encoding brainfart fix) - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Extensions, patch v19 (encoding brainfart fix)
Date
Msg-id m2wrn7asi7.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Extensions, patch v19 (encoding brainfart fix) (was: Extensions, patch v18 (merge against master, bitrot-only-fixes))  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
Responses Extensions, patch v20 (bitrot fixes) (was: Extensions, patch v19 (encoding brainfart fix))  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
Itagaki Takahiro <itagaki.takahiro@gmail.com> writes:
> You probably compared wrong versions of source trees. The patch contains
> many diffs not related to EXTENSION. It cannot be applied cleanly.

Ouch, sorry about that, will revise soon'ish.  Meanwhile the git repo is
still available here:
 http://git.postgresql.org/gitweb?p=postgresql-extension.git;a=shortlog;h=refs/heads/extension

> BTW, only earthdistance.sql.in has @extschema@.
> Didn't you forget to remove it?

No. It so happens that earthdistance depends on cube and that we agreed
on not implement dependencies between extensions for the first patch.
The problem here is that ALTER EXTENSION earthdistance SET SCHEMA foo;
would relocate cube objects too, because there's nothing to stop the
recursive walking at the right spot.  So earthdistance.control states
that earthdistance is not relocatable for now.

And a non relocatable extension will use @extschema@ so that users still
get a say in where to install it…

> I've not read the patch well yet, but I'd like to make sure of
> two specs in the patch:
>
> #1. I found the patch specifies "version" in each control file. We will
> need to maintain them manually, but I assume it was a conclusion in the
> discussion for v18 patch. So, no more changes are required here.

Exactly, the consensus seems to be that we *want* to maintain separate
versions number for each contrib.

> #2. The patch replaces "\i XXX.sql" to "CREATE EXTENSION XXX". They are a
> bit different because CREATE EXTENSION uses the installed sql files instead
> of the source directory. But I think this is the correct behavior. We should
> have used only installed files because they are used in "make *installcheck*".

Yeah.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: unlogged tables
Next
From: Jan Urbański
Date:
Subject: exceptions not present in plpy with Python 3