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