Re: on placeholder entries in view rule action query's range table

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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:09:43
Message-ID: 67cc45dd-fe02-e40e-13cc-90d888b743e8@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2023-01-12 Th 00:12, Justin Pryzby wrote:
> On Wed, Jan 11, 2023 at 10:45:33PM -0500, Tom Lane wrote:
>> Amit Langote <amitlangote09(at)gmail(dot)com> writes:
>>> On Thu, Jan 12, 2023 at 10:06 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> I've pushed this with some cleanup --- aside from fixing
>>>> outfuncs/readfuncs, I did some more work on the comments, which
>>>> I think you were too sloppy about.
>>> Thanks a lot for the fixes.
>> It looks like we're not out of the woods on this: the buildfarm
>> members that run cross-version-upgrade tests are all unhappy.
>> Most of them are not reporting any useful details, but I suspect
>> that they are barfing because dumps from the old server include
>> table-qualified variable names in some CREATE VIEW commands while
>> dumps from HEAD omit the qualifications. I don't see any
>> mechanism in TestUpgradeXversion.pm that could deal with that
>> conveniently, and in any case we'd have to roll out a client
>> script update to the affected animals. I fear we may have to
>> revert this pending development of better TestUpgradeXversion.pm
>> support.
> There's a diffs available for several of them:
>
> - SELECT citext_table.id,
> - citext_table.name
> + SELECT id,
> + name
>
> It looks like TestUpgradeXversion.pm is using the diff command I sent to
> get tigher bounds on allowable changes.
>
> 20210415153722(dot)GL6091(at)telsasoft(dot)com
>
> 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 }'
>
> You'd still have to wait for it to be deployed, though.

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.

Another approach might be simply to increase the latitude allowed for
old versions <= 15 with new versions >= 16. Currently we allow 90 for
cases where the versions differ, but we could increase it to, say, 200
in such cases (we'd need to experiment a bit to find the right limit).

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Sharma 2023-01-12 14:38:55 Re: Minimal logical decoding on standbys
Previous Message Imseih (AWS), Sami 2023-01-12 14:02:33 Re: Add index scan progress to pg_stat_progress_vacuum