I wrote:
> Alex Williams <valencesh...@protonmail.com> writes:
>> [ gripes about pg_dump printing REPLICA IDENTITY NOTHING for a view ]
> This is fixed in v10 and up thanks to d8c05aff5. I was hesitant to
> back-patch that at the time, but now that it's survived in the field
> for a couple years, I think a good case could be made for doing so.
> After a bit of looking around, the main argument I can find against
> it is that emitting 'CREATE OR REPLACE VIEW' in a dropStmt will
> break pg_restore versions preceding this commit:
> Author: Tom Lane <t...@sss.pgh.pa.us>
> Branch: master Release: REL_10_BR [ac888986f] 2016-11-17 14:59:13 -0500
> Branch: REL9_6_STABLE Release: REL9_6_2 [0eaa5118a] 2016-11-17 14:59:19 -0500
> Branch: REL9_5_STABLE Release: REL9_5_6 [a7864037d] 2016-11-17 14:59:23 -0500
> Branch: REL9_4_STABLE Release: REL9_4_11 [e69b532be] 2016-11-17 14:59:26 -0500
> Improve pg_dump/pg_restore --create --if-exists logic.
After further digging, I remembered that we bumped the archive file
version number in 3d2aed664 et al. to fix CVE-2018-1058. So current
versions of pg_dump already emit archive files that will be rejected
by pg_restore versions preceding the above fix, and so there should be
no downside to emitting data that depends on it.
I'll go see about backpatching d8c05aff5.
regards, tom lane
