Re: some more pg_dump refactoring

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: some more pg_dump refactoring
Date: 2020-06-29 13:13:24
Message-ID: 458c97a0-1841-88c9-eddf-a45a8ba86811@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-06-25 08:58, Fabien COELHO wrote:
> 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.

This was the style that was introduced by
daa9fe8a5264a3f192efa5ddee8fb011ad9da365.

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

That was a mistake.

> 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?

I think that could make sense, but the current style was introduced by
daa9fe8a5264a3f192efa5ddee8fb011ad9da365. Should we revise that?

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

It's not handled fully consistently in pg_dump. But my understanding is
that this is no longer necessary because pg_dump explicitly sets the
search path before running.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
v2-0001-pg_dump-Reorganize-dumpFunc-and-dumpAgg.patch text/plain 22.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ants Aasma 2020-06-29 13:23:41 Re: track_planning causing performance regression
Previous Message higuchi.daisuke@fujitsu.com 2020-06-29 13:00:25 RE: [Bug fix]There is the case archive_timeout parameter is ignored after recovery works.