Re: pg_dump bug in 9.4beta2 and HEAD
От | Pavel Stehule |
---|---|
Тема | Re: pg_dump bug in 9.4beta2 and HEAD |
Дата | |
Msg-id | CAFj8pRBi8B1TyiSMs62_8NGH3W6pjvf-gmuc3n0RW_c2wDAoww@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_dump bug in 9.4beta2 and HEAD (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-hackers |
2014-09-30 17:18 GMT+02:00 Alvaro Herrera <alvherre@2ndquadrant.com>:
I have pushed this fix, except that instead of parsing the OID from the
dropStmt as in your patch, I used te->catalogId.oid, which is much
simpler.
yes, it is much better
I tested this by pg_restoring to 8.4 (which doesn't have
pg_largeobject_metadata); there is no error raised:
LOG: sentencia: SELECT CASE WHEN EXISTS(SELECT 1 FROM pg_catalog.pg_largeobject WHERE loid = '43748') THEN pg_catalog.lo_unlink('43748') END;
In 9.0 the command is the new style:
LOG: sentencia: SELECT pg_catalog.lo_unlink(oid) FROM pg_catalog.pg_largeobject_metadata WHERE oid = '43748';
So it's all fine. I guess it's fortunate that we already had the
DropBlobIfExists() function.
Now a further problem I notice is all the *other* commands for which we
inject the IF EXISTS clause; there is no support for those in older
servers, so they throw errors if --if-exists is given in the pg_restore
line. I think we can just say that --if-exists is not supported for
older servers; as Heikki said, we don't promise that pg_dump is
compatible with older servers anyway. In my test database, several
commands errored out when seeing the EXTENSION in CREATE EXTENSION IF EXISTS.
So we're okay now.
great,
Thank you very much
Pavel
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: