Re: Inline Extension
Dimitri Fontaine <dimitri@2ndquadrant.fr>
From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>, Tom Lane <tgl@sss.pgh.pa.us>, Daniel Farina <daniel@heroku.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, pgsql-hackers@postgresql.org
Date: 2012-01-23T15:26:22Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes: > Hmm. But CREATE EXTENSION / ALTER EXTENSION doesn't seem right, > because the files in the directory correspond to *available* > extensions, not already-created ones. We need some way of dumping and I would have limited the dump query to only known installed extensions, right. The update scripts are still needed because with inline extensions you typically never see a 1.2 script but a 1.0 then 1.0--1.1 and then a 1.1--1.2. > restoring the files themselves, not the extension that can be created > from them. I suspect internal functions (pg_whatever) make more sense > than new SQL syntax, since this is really only to make pg_dump happy. That could well be, yes, but what would this function do that the commands are not doing? I'm ok not to invent specific syntax to solve that problem, I just think that we should already have all we need :) >> Or do you still want to insist that dump/restore shouldn't care about >> any extension, inline or not, and so you're given the responsibility to >> do the exact same thing yourself on the client side? > > How about adding a new pg_dump option to suppress this part of the dump? Makes sense, indeed. Well one could of course manually filter the dump object list too, of course… Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support