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
