Re: Refactoring pg_dump's getTables()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Refactoring pg_dump's getTables()
Date: 2021-10-19 21:27:30
Message-ID: 2007363.1634678850@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> On 17 Oct 2021, at 22:05, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Isaac Morland 2021-10-19 21:29:16 Re: CREATE ROLE IF NOT EXISTS
Previous Message Bossart, Nathan 2021-10-19 21:01:13 Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES