On 01/18/2011 12:11 PM, Anssi Kääriäinen wrote:
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.
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...
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
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
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: