Re: Refactoring pg_dump's getTables() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Refactoring pg_dump's getTables()
Date
Msg-id 2007363.1634678850@sss.pgh.pa.us
Whole thread Raw
In response to Re: Refactoring pg_dump's getTables()  (Daniel Gustafsson <daniel@yesql.se>)
List 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 by date:

Previous
From: Greg Stark
Date:
Subject: Re: Extending amcheck to check toast size and compression
Next
From: Isaac Morland
Date:
Subject: Re: CREATE ROLE IF NOT EXISTS