From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
cc: cam.daniel@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16655: pg_dump segfault when excluding postgis table
In-reply-to: <20201007020820.GY3063@tamriel.snowman.net>
References: <20201007020820.GY3063@tamriel.snowman.net>
Comments: In-reply-to Stephen Frost <sfrost@snowman.net>
	message dated "Tue, 06 Oct 2020 22:08:20 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2232787.1602089765.1@sss.pgh.pa.us>
Date: Wed, 07 Oct 2020 12:56:05 -0400
Message-ID: <2232788.1602089765@sss.pgh.pa.us>
Precedence: bulk

Stephen Frost <sfrost@snowman.net> writes:
> This all sounds like a reasonable approach to me.  I've gone back and
> looked through things a bit and agree that processExtensionTables really
> should be setting interesting to true for extension config tables when
> we decide we want to include them.  Your 0003 patch looks correct to me,
> and it does seem like we need to go all the way back with that.

Pushed now, thanks for looking it over.

I ended up dropping 0001 (the ncheck refactoring).  That's not really
relevant to the bug fix, and it occurred to me that dumping core if
the checkexprs data isn't there isn't such a bad thing.  0001 would
have led us to silently act as though the table has no CHECK constraints,
contrary to reality, if we reached one of those loops without having
loaded the requisite data.  Crashing is better --- think of it as a
free Assert ;-).

			regards, tom lane