Re: Refactoring pg_dump's getTables()

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Refactoring pg_dump's getTables()
Date: 2021-10-17 20:05:25
Message-ID: 202110172005.z4gsdny63hzt@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2021-Oct-16, Tom Lane wrote:

> Attached is a proposed patch that refactors getTables() along the
> same lines as some previous work (eg 047329624, ed2c7f65b, daa9fe8a5)
> to avoid having multiple partially-redundant copies of the SQL query.
> This gets rid of nearly 300 lines of duplicative spaghetti code,
> creates a uniform style for dealing with cross-version changes
> (replacing at least three different methods currently being used
> for that in this same stretch of code), and allows moving some
> comments to be closer to the code they describe.

Yeah, this seems a lot better than the original coding. Maybe I would
group together the changes that all require the same version test,
rather than keeping the output columns in the same order. This reduces
the number of branches. Because the follow-on code uses column names
rather than numbers, there is no reason to keep related columns
together. But it's a clear improvement even without that.

Álvaro Herrera 39°49'30"S 73°17'W —
"Puedes vivir sólo una vez, pero si lo haces bien, una vez es suficiente"

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Gilles Darold 2021-10-17 21:01:08 Re: [PATCH] Proposal for HIDDEN/INVISIBLE column
Previous Message Tom Lane 2021-10-17 18:45:13 pg_dump does way too much before acquiring table locks