Re: some more pg_dump refactoring - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: some more pg_dump refactoring
Date
Msg-id alpine.DEB.2.22.394.2006250820020.2939276@pseudo
Whole thread Raw
In response to some more pg_dump refactoring  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: some more pg_dump refactoring  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Hallo Peter,

My 0.02 €:

Patch applies cleanly, compiles, make check and pg_dump tap tests ok. The 
refactoring is a definite improvements.

You changed the query strings to use "\n" instead of " ". I would not have 
changed that, because it departs from the style around, and I do not think 
it improves readability at the C code level.

I tried to check manually and randomly that the same query is built for 
the same version, although my check may have been partial, especially on 
the aggregate query which does not comment about what is changed between 
versions, and my eyes are not very good at diffing.

I've notice that some attributes are given systematic replacements (eg 
proparallel), removing the need to test for presence afterwards. This 
looks fine to me.

However, on version < 8.4, ISTM that funcargs and funciargs are always 
added: is this voluntary?.

Would it make sense to accumulate in the other direction, older to newer, 
so that new attributes are added at the end of the select?

Should array_to_string be pg_catalog.array_to_string? All other calls seem 
to have an explicit schema.

I'm fine with inlining most PQfnumber calls.

I do not have old versions at hand for testing.

> Here is a patch to reorganize dumpFunc() and dumpAgg() in pg_dump, similar to 
> daa9fe8a5264a3f192efa5ddee8fb011ad9da365.  Instead of repeating the almost 
> same large query in each version branch, use one
> query and add a few columns to the SELECT list depending on the
> version.  This saves a lot of duplication.
>
> I have tested this with various old versions of PostgreSQL I had available, 
> but a bit more random testing with old versions would be welcome.

-- 
Fabien.

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: archive status ".ready" files may be created too early
Next
From: ROS Didier
Date:
Subject: RE: PostgreSQL and big data - FDW