From: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Fast default stuff versus pg_upgrade |
Date: | 2018-06-21 17:28:46 |
Message-ID: | 47905c79-f6b5-a973-766b-822424b7b4ca@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 06/21/2018 01:18 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
>> On 06/21/2018 12:39 PM, Tom Lane wrote:
>>> Andres Freund <andres(at)anarazel(dot)de> writes:
>> On June 21, 2018 9:04:28 AM PDT, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> This isn't really ready to go. One clear problem is that you broke
>> pg_dump'ing from any pre-v11 version, because you did not add suitable
>> null outputs to the pre-v11 query variants in getTableAttrs.
>> I followed the pattern used for attidentity. But why will it spit out
>> warnings? It doesn't ask for the missing stuff from an older version.
> Oh, I see. Well, the short answer is that that's not the style we use
> in pg_dump, and the attidentity code is inappropriate/wrong too IMO.
> When something has been done one way a hundred times before, thinking
> you're too smart for that and you'll do it some other way does not lend
> itself to code clarity or reviewability.
>
> I might be OK with a patch that converts *all* of pg_dump's cross-version
> difference handling code to depend on PQfnumber silently returning -1
> rather than failing, but I don't want to see it done like that in just
> one or two places.
>
>
I don't mind changing it. But please note that I wouldn't have done it
that way unless there were a precedent. I fully expected to add dummy
values to all the previous queries, but when I couldn't find attidentity
in them to put them next to I followed that example.
I don't think it's at all a bad idea, TBH. It means you only have to add
one query per version rather than having to adjust all of them.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2018-06-21 17:30:03 | Re: location reporting in TAP test failures |
Previous Message | Tom Lane | 2018-06-21 17:18:22 | Re: Fast default stuff versus pg_upgrade |