Re: Refactoring pg_dump's getTables()

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Refactoring pg_dump's getTables()
Дата
Msg-id 2007363.1634678850@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Refactoring pg_dump's getTables()  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers
Daniel Gustafsson <daniel@yesql.se> writes:
> On 17 Oct 2021, at 22:05, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>> Maybe I would group together the changes that all require the same version
>> test, rather than keeping the output columns in the same order.

> I agree with that, if we're doing all this we might as well go all the way for
> readability.

I had a go at doing that, but soon decided that it wasn't as great an
idea as it first seemed.  There are two problems:

1. It's not clear what to do with fields where there are three or more
variants, such as reloptions and checkoptions.

2. Any time we modify the behavior for a particular field, we'd
have to merge or un-merge it from the stanza for the
previously-most-recently-relevant version.  This seems like it'd
be a maintenance headache and make patch footprints bigger than they
needed to be.

So I ended up not doing very much merging.  I did make an effort
to group the fields in perhaps a slightly more logical order
than before.

            regards, tom lane



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

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Extending amcheck to check toast size and compression
Следующее
От: Isaac Morland
Дата:
Сообщение: Re: CREATE ROLE IF NOT EXISTS