Re: Fast default stuff versus pg_upgrade - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fast default stuff versus pg_upgrade
Date
Msg-id 15540.1529597068@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fast default stuff versus pg_upgrade  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Responses Re: Fast default stuff versus pg_upgrade
Re: Fast default stuff versus pg_upgrade
List pgsql-hackers
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> Patch after pgindent attached. This will involve a catversion bump since 
> we're adding a new function.

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.

Personally, I'd have made the pg_dump changes simpler and cheaper by
storing only one new value per column not two.  You could have just
stored attmissingval, or if you want to be paranoid you could do

    case when atthasmissing then attmissingval else null end

We could do without the unrelated whitespace changes in dumpDefaultACL,
too (or did pgindent introduce those?  Seems surprising ... oh, looks
like "type" has somehow snuck into typedefs.list.  Time for another
blacklist entry.)

In dumpTableSchema, I'd suggest emitting the numeric table OID, rather
than hacking around with regclass.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: libpq compression
Next
From: Tom Lane
Date:
Subject: Re: Fast default stuff versus pg_upgrade