Re: Fast default stuff versus pg_upgrade
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@lists.postgresql.org
Date: 2018-06-21T17:18:22Z
Lists: pgsql-hackers
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes: > On 06/21/2018 12:39 PM, Tom Lane wrote: >> Andres Freund <andres@anarazel.de> writes: > On June 21, 2018 9:04:28 AM PDT, Tom Lane <tgl@sss.pgh.pa.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. regards, tom lane
Commits
-
Allow for pg_upgrade of attributes with missing values
- 2448adf29c54 11.0 landed