Re: REVIEW: Extensions support for pg_dump

On 01/18/2011 12:11 PM, Anssi Kääriäinen wrote:
> The only question here is should CREATE OR REPLACE be allowed. I just
> realized this could present a new problem. If I am not mistaken, when
> loading from dump, you suddenly get the extension's version back, not
> the one you defined in CREATE OR REPLACE. If this is the case, this
> should NOT be allowed. And by the same reasoning, ALTER FUNCTION
> [anything] should not be allowed either. Or at least then the
> function/(or any object for that matter) should be restored somehow from
> the backup, not from the extension files.
>
> I still haven't had the time to start pg_dump reviewing, so I haven't
> verified if this is really a problem. But I suspect so...
Ok, verified at least for CREATE OR REPLACE, ALTER FUNCTION RENAME and 
ALTER FUNCTION SET search_path. You will get the extensions version back 
when restoring from plain sql dump, not the CORed function, rename is 
lost and same for search_path. I suspect this is a problem for any 
object type supported in extensions. But unfortunately I do not have 
time to verify that.

One more problem with pg_dump. If you have CREATE EXTENSION in you 
extensions .sql file, you will have problems restoring. I know it is 
stupid to do so, but still CREATE EXTENSION inside CREATE EXTENSION 
should be disallowed, as it is possible you find out too late that this 
is stupid thing to do. Also, the functions created in the "recursive" 
CREATE EXTENSION will be dumped, and the dependencies are not created 
correctly.

Unfortunately I have used up all the time I have for reviewing this 
patch. I can arrange some more time, maybe late this week, maybe a bit 
later. So, I do not have time to do the pg_dump part review in full 
detail right now. Still, I hope the work I have done is helpful.

Should I write up a post that contains all the current outstanding 
issues in one post, or is it enough to just link this thread in the 
CommitFest application?

  - Anssi