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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, vignesh C <vignesh21@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-01-12T03:45:33Z
Lists: pgsql-hackers
Amit Langote <amitlangote09@gmail.com> writes:
>  On Thu, Jan 12, 2023 at 10:06 AM Tom Lane <tgl@sss.pgh.pa.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.

			regards, tom lane



Commits

  1. Acquire locks on views in AcquirePlannerLocks, too.

  2. Get rid of the "new" and "old" entries in a view's rangetable.

  3. vacuumlazy.c: Save get_database_name() in vacrel.