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 по дате отправления:

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: Last Commitfest patches waiting review
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: open items for 9.4