From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: on placeholder entries in view rule action query's range table |
Date: | 2023-01-12 14:54:09 |
Message-ID: | 951602.1673535249@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2023-01-12 15:03:53 | Re: Remove source code display from \df+? |
Previous Message | Masahiko Sawada | 2023-01-12 14:50:32 | Re: [PoC] Improve dead tuple storage for lazy vacuum |