Re: BUG #17151: A SEGV in optimizer - Mailing list pgsql-bugs

From Masahiko Sawada
Subject Re: BUG #17151: A SEGV in optimizer
Date
Msg-id CAD21AoC85wAip6EEitcNJbwUF+RCkW2H+veFmNbmJJRhaSx71w@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17151: A SEGV in optimizer  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #17151: A SEGV in optimizer  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Thu, Aug 19, 2021 at 8:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I wrote:
> > (This passes check-world, but I've not double-checked to make sure
> > that inFromCl will be set in exactly the cases we want.)
>
> After studying the code a bit more, I remembered why my hindbrain
> was feeling uncomfortable about that coding: parsenodes.h says that
> inFromCl is quasi-deprecated and not used anymore during parsing.
>
> However, we can't really use the ParseNamespaceItem data structure
> for this purpose, because baserels should be available to lock
> whether or not they are visible according to join aliasing rules.
> I don't see a lot of point to inventing some complicated add-on
> for this when inFromCl will serve fine.  So I think we should just
> adjust the relevant comments, say like the attached.

The patch looks good to me. I've also confirmed that it passed
check-world and fixed the problem.

> We probably need some regression test cases added (I wonder whether
> FOR UPDATE in rule actions is covered at all ATM).  Otherwise
> I feel like this is OK to commit.

+1 for adding at least two queries reported on this thread to regression tests.

Regards,

--
Masahiko Sawada
EDB:  https://www.enterprisedb.com/



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17151: A SEGV in optimizer
Next
From: Julien Rouhaud
Date:
Subject: Re: BUG #17148: About --no-strict-names option and --quiet option of pg_amcheck command