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(dot)eisentraut(at)2ndquadrant(dot)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
>

--
Derek Nelson
CEO & Co-Founder, PipelineDB <http://www.pipelinedb.com>
(650) 564-7097 | LinkedIn <http://www.linkedin.com/in/derekjn>