Michael Paquier <mich...@paquier.xyz> writes:
> On Tue, Jul 14, 2020 at 11:14:50AM +0200, Julien Rouhaud wrote:
>> Note that those extraneous queries were found while trying to dump
>> data out of a corrupted database. The issue wasn't an excessive
>> runtime but corrupted catalog entries, so bypassing this code (since I
>> was only interested in the data anyway) was simpler than trying to
>> recover yet other corrupted rows.
> Yeah, I don't see actually why this argument can prevent us from doing
> a micro optimization if it proves to work correctly.
The main thing I'm wondering about is whether not fetching these objects
could lead to failing to detect an important dependency chain. IIRC,
pg_dump simply ignores pg_depend entries that mention objects it has not
loaded, so there is a possible mechanism for that. However, it's hard to
see how a --data-only dump could end up choosing an invalid dump order on
that basis. It doesn't seem like safe load orders for the table data
objects could depend on what is referenced by defaults or CHECK
constraints.
But ... I've only spent a few minutes thinking about it, so maybe
I'm missing something.
(Note that we disallow sub-queries in CHECK constraints, and also
disclaim responsibility for what happens if you cheat by hiding
the subquery in a function. So while it's certainly possible to
build CHECK constraints that only work if table X is loaded before
table Y, pg_dump already doesn't guarantee that'll work, --data-only
or otherwise.)
regards, tom lane
