Re: some more pg_dump refactoring

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: some more pg_dump refactoring
Дата
Msg-id 458c97a0-1841-88c9-eddf-a45a8ba86811@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: some more pg_dump refactoring  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: some more pg_dump refactoring  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "higuchi.daisuke@fujitsu.com"
Дата:
Сообщение: RE: [Bug fix]There is the case archive_timeout parameter is ignoredafter recovery works.
Следующее
От: Ants Aasma
Дата:
Сообщение: Re: track_planning causing performance regression