Re: Tables created WITH OIDS cannot be dumped/restored properly
Thanks for the quick turnaround! I considered only changing the type of currWithOids but thought it may make sense to change both for uniformity as well as future proofing against a similar issue being introduced again moving forward. In any case, this seems like a good, minimal fix--thanks again!
ᐧ
On Fri, Nov 9, 2018 at 12:26 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
On 01/11/2018 20:56, Derek Nelson wrote:
> Hello PG community! I'm one of the PipelineDB developers (PostgreSQL
> extension) and as we've begun adding support for PG 11 our test
> infrastructure identified an issue with dumping/restoring tables created
> WITH OIDs. Naturally this also affects pg_upgrade.
>
> If a table is created WITH OIDS, dumped and then restored, the resulting
> table will not contain the OID column.
Good catch. It's actually only if the affected table is the first table
in the output (or perhaps some other narrow circumstances). We do have
a test case for WITH OIDS tables, but that table ends up not the first
in the output.
I propose to apply the attached patch. It's slightly different from
yours in that I don't think we need to change the type of the withOids
field.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-bugs по дате отправления:
Предыдущее
От: Etsuro FujitaДата:
Сообщение: Re: BUG #15449: file_fdw using program cause exit code error whenusing LIMIT
Следующее
От: PG Bug reporting formДата:
Сообщение: BUG #15499: pg_dump does not read connection URL from environmentvariable