Re: ArchiveEntry optional arguments refactoring

Hi,

On 2019-01-17 09:29:04 -0800, Andres Freund wrote:
> On 2019-01-17 10:23:39 -0500, Tom Lane wrote:
> > I don't buy the argument that this would move the goalposts in terms
> > of how much work it is to add a new argument.  You'd still end up
> > touching every call site.
> 
> Why? A lot of arguments that'd be potentially added or removed would not
> be set by each callsites.
> 
> If you e.g. look at
> 
> you can see that a lot of changes where like
>         ArchiveEntry(fout, nilCatalogId, createDumpId(),
>                      "pg_largeobject", NULL, NULL, "",
> -                    false, "pg_largeobject", SECTION_PRE_DATA,
> +                    "pg_largeobject", SECTION_PRE_DATA,
>                      loOutQry->data, "", NULL,
>                      NULL, 0,
>                      NULL, NULL);
> 
> i.e. just removing a 'false' argument. In like 70+ callsites. With the
> above scheme, we'd instead just have removed a single .withoids = true,
> from dumpTableSchema()'s ArchiveEntry() call.

the "at" I was trying to reference above is
578b229718e8f15fa779e20f086c4b6bb3776106 / the WITH OID removal, and
therein specifically the pg_dump changes.

Greetings,

Andres Freund