Re: some more pg_dump refactoring

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.