Re: Refactoring pg_dump's getTables()

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Refactoring pg_dump's getTables()
Дата
Msg-id 202110172005.z4gsdny63hzt@alvherre.pgsql
обсуждение исходный текст
Ответ на Refactoring pg_dump's getTables()  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Refactoring pg_dump's getTables()  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Refactoring pg_dump's getTables()  (Daniel Gustafsson <daniel@yesql.se>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: pg_dump does way too much before acquiring table locks
Следующее
От: Gilles Darold
Дата:
Сообщение: Re: [PATCH] Proposal for HIDDEN/INVISIBLE column