|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
|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|