Re: ArchiveEntry optional arguments refactoring
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-01-17T15:23:39Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Jan-16, Dmitry Dolgov wrote:
>> ArchiveEntry((ArchiveArgs){.tablespace = 3,
>> .dumpFn = somefunc,
>> ...});
> Is there real savings to be had by doing this? What would be the
> arguments to each function? Off-hand, I'm not liking this idea too
> much.
I'm not either. What this looks like it will mainly do is create
a back-patching barrier, with little if any readability improvement.
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.
regards, tom lane
Commits
-
Add ArchiveOpts to pass options to ArchiveEntry
- f831d4accda0 12.0 landed
-
Remove WITH OIDS support, change oid catalog column visibility.
- 578b229718e8 12.0 cited