Re: on placeholder entries in view rule action query's range table - Mailing list pgsql-hackers

From Tom Lane
Subject Re: on placeholder entries in view rule action query's range table
Date
Msg-id 951602.1673535249@sss.pgh.pa.us
Whole thread Raw
In response to Re: on placeholder entries in view rule action query's range table  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: on placeholder entries in view rule action query's range table
Re: on placeholder entries in view rule action query's range table
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> On 2023-01-12 Th 00:12, Justin Pryzby wrote:
>> It's ugly and a terrible hack, and I don't know whether anyone would say
>> it's good enough, but one could can probably avoid the diff like:
>> sed -r '/CREATE/,/^$/{ s/\w+\.//g }'

> That looks quite awful. I don't think you could persuade me to deploy it
> (We don't use sed anyway). It might be marginally better if the pattern
> were /CREATE.*VIEW/ and we ignored that first line, but it still seems
> awful to me.

Yeah, does not sound workable: it would risk ignoring actual problems.

I was wondering whether we could store a per-version patch or Perl
script that edits the old dump file to remove known discrepancies
from HEAD.  If well-maintained, that could eliminate the need for the
arbitrary "fuzz factors" that are in TestUpgradeXversion.pm right now.
I'd really want these files to be kept in the community source tree,
though, so that we do not need a new BF client release to change them.

This isn't the first time this has come up, but now we have a case
where it's actually blocking development, so maybe it's time to
make something happen.  If you want I can work on a patch for the
BF client.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum
Next
From: Magnus Hagander
Date:
Subject: Re: Remove source code display from \df+?