Re: ArchiveEntry optional arguments refactoring - Mailing list pgsql-hackers

From Andres Freund
Subject Re: ArchiveEntry optional arguments refactoring
Date
Msg-id 20190117182632.qdmljoyt32hnchtf@alap3.anarazel.de
Whole thread Raw
In response to Re: ArchiveEntry optional arguments refactoring  (Andres Freund <andres@anarazel.de>)
Responses Re: ArchiveEntry optional arguments refactoring  (Dmitry Dolgov <9erthalion6@gmail.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: ArchiveEntry optional arguments refactoring
Next
From: Chris Travers
Date:
Subject: Re: Proposal for Signal Detection Refactoring