Re: Bug in query rewriter - hasModifyingCTE not getting set

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Nancarrow <gregn4422(at)gmail(dot)com>
Cc: "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug in query rewriter - hasModifyingCTE not getting set
Date: 2021-09-08 14:28:53
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Greg Nancarrow <gregn4422(at)gmail(dot)com> writes:
> On Wed, Sep 8, 2021 at 8:00 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Now, we could potentially make this work if we wrote code to run
>> through the copied rtable entries (recursively) and increment the
>> appropriate ctelevelsup fields by one. That would essentially
>> have to be a variant of IncrementVarSublevelsUp that *only* acts
>> on ctelevelsup and not other level-dependent fields. That's
>> what I meant when I spoke of moving mountains: the amount of code
>> that would need to go into this seems out of all proportion to
>> the value. I think we should just throw an error, instead.
>> At least till such time as we see actual field complaints.

> [I don't think Tsunakawa-san will be responding to this any time soon]

Oh! I'd not realized that he'd dropped out of the community, but
checking my mail folder, I don't see any messages from him in months
... and his email address is bouncing, too. Too bad.

> I proposed a patch for this issue in a separate thread:

Right, that one looks like an appropriate amount of effort
(at least till someone gets way more excited about the case
than I am). I will mark this CF item Returned With Feedback
and go see about that one.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2021-09-08 14:40:35 Re: Avoid stuck of pbgench due to skipped transactions
Previous Message oswaldo.bregnoles 2021-09-08 14:21:30 Migração Postgresql 8.3 para versão Postgresql 9.3