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