Re: Refactoring pg_dump's getTables() - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Refactoring pg_dump's getTables()
Date
Msg-id 202110172005.z4gsdny63hzt@alvherre.pgsql
Whole thread Raw
In response to Refactoring pg_dump's getTables()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Refactoring pg_dump's getTables()
Re: Refactoring pg_dump's getTables()
List 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  —  https://www.EnterpriseDB.com/
"Puedes vivir sólo una vez, pero si lo haces bien, una vez es suficiente"



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: pg_dump does way too much before acquiring table locks
Next
From: Gilles Darold
Date:
Subject: Re: [PATCH] Proposal for HIDDEN/INVISIBLE column