Re: Bug in pg_dump/restore -o
От | Tom Lane |
---|---|
Тема | Re: Bug in pg_dump/restore -o |
Дата | |
Msg-id | 25535.1011306425@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Bug in pg_dump/restore -o (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Bug in pg_dump/restore -o
Re: Bug in pg_dump/restore -o |
Список | pgsql-hackers |
Bruce Momjian <pgman@candle.pha.pa.us> writes: > I think I see the cause. I created a simple table and then generated > the dump. I found this that the normal table had its COPY data in > binary format while the max oid dump was pure ASCII. My guess is that > the max oid dump code isn't calling the right routine to dump its data. Indeed, the max oid dump code doesn't look like it's been clued at all about interoperating with the new pg_dump output code. It can't just intermix commands and data into one string and expect pg_restore to cope. Compare what happens in dumpClasses/dumpClasses_nodumpData to what's being done in setMaxOid. Philip, you're probably the best-qualified to fix this, but if you don't have time today then I can work on it. I don't want to delay RC1 for this... regards, tom lane
В списке pgsql-hackers по дате отправления: