Re: Extensions support for pg_dump, patch v27 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Extensions support for pg_dump, patch v27
Date
Msg-id 24969.1296074328@sss.pgh.pa.us
Whole thread Raw
In response to Re: Extensions support for pg_dump, patch v27  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Extensions support for pg_dump, patch v27  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Re: Extensions support for pg_dump, patch v27  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Mph.  Although such an extension should certainly carry a dependency on
>> the schema it's using, I'm not sure that it makes sense to consider that
>> the extension (as opposed to its contained objects) belongs to the
>> schema.

> Well yes, extension are not living in a schema, we just offer users a
> way to influence the script as far as where the extension's objects are
> to be found and register a dependency so that it's easy to remember what
> the users asked.  So that for example we are able to act the same way on
> pg_restore.

Oh: then you're doing it wrong.  If you want to remember that WITH
SCHEMA was specified, you need to explicitly store that as another
column in pg_extension.  You should not be depending on the dependency
mechanism to remember that for you, any more than we'd use pg_depend to
remember a table's relnamespace.  The dependency mechanism is there
to figure out the consequences of a DROP command, it's not there to
remember arbitrary facts.  (And yes, I know that we've cheated on that
principle a few times before; but you can't do it here.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alexey Klyukin
Date:
Subject: Re: arrays as pl/perl input arguments [PATCH]
Next
From: "Kevin Grittner"
Date:
Subject: Re: SSI patch version 14