Greg Nancarrow writes:
> On Wed, Sep 8, 2021 at 8:00 AM Tom Lane 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 varian
On Wed, Sep 8, 2021 at 8:00 AM Tom Lane wrote:
>
> "tsunakawa.ta...@fujitsu.com" writes:
> > The attached patch is based on your version. It includes cosmetic
> > changes to use = instead of |= for boolean variable assignments.
>
> Now, we could potentially make this work if we wrote code to run
"tsunakawa.ta...@fujitsu.com" writes:
> The attached patch is based on your version. It includes cosmetic
> changes to use = instead of |= for boolean variable assignments.
I think that's less "cosmetic" than "gratuitous breakage". The point
here is that we are combining two rtables, so the que
From: Tom Lane
> "tsunakawa.ta...@fujitsu.com" writes:
> > Finally, I think I've understood what you meant. Yes, the current code
> > seems
> to be wrong.
>
> I'm fairly skeptical of this claim, because that code has stood for a
> long time. Can you provide an example (not involving hasModify
"tsunakawa.ta...@fujitsu.com" writes:
> From: Tom Lane
>> I think either the bit about rule_action is unnecessary, or most of
>> the code immediately above this is wrong, because it's only updating
>> flags in sub_action. Why do you think it's necessary to change
>> rule_action in addition to su
From: Tom Lane
> I think either the bit about rule_action is unnecessary, or most of
> the code immediately above this is wrong, because it's only updating
> flags in sub_action. Why do you think it's necessary to change
> rule_action in addition to sub_action?
Finally, I think I've understood w
From: Tom Lane
> Greg Nancarrow writes:
> > On Sun, Feb 7, 2021 at 10:03 AM Tom Lane wrote:
> >> I think either the bit about rule_action is unnecessary, or most of
> >> the code immediately above this is wrong, because it's only updating
> >> flags in sub_action. Why do you think it's necessar
From: Tom Lane
> In view of this, maybe the right thing is to disallow modifying CTEs
> in rule actions in the first place. I see we already do that for
> views (i.e. ON SELECT rules), but they're not really any safer in
> other types of rules.
You meant by views something like the following, di
I wrote:
> That semantic issue doesn't get any less pressing just because the query
> was generated by rewrite. So I now think that what we have to do is
> throw an error if we have a modifying CTE and sub_action is different
> from rule_action. Not quite sure how to phrase the error though.
Ano
Greg Nancarrow writes:
> On Sun, Feb 7, 2021 at 10:03 AM Tom Lane wrote:
>> I think either the bit about rule_action is unnecessary, or most of
>> the code immediately above this is wrong, because it's only updating
>> flags in sub_action. Why do you think it's necessary to change
>> rule_action
On Sun, Feb 7, 2021 at 10:03 AM Tom Lane wrote:
>
> Greg Nancarrow writes:
> > I found a bug in the query rewriter. If a query that has a modifying
> > CTE is re-written, the hasModifyingCTE flag is not getting set in the
> > re-written query.
>
> Ugh.
>
> > I've attached the patch with the sugge
After poking around a bit more, I notice that the hasRecursive flag
really ought to get propagated as well, since that's also an attribute
of the CTE list. That omission doesn't seem to have any ill effect
today, since nothing in planning or execution looks at that flag, but
someday it might. So
Greg Nancarrow writes:
> I found a bug in the query rewriter. If a query that has a modifying
> CTE is re-written, the hasModifyingCTE flag is not getting set in the
> re-written query.
Ugh.
> I've attached the patch with the suggested fix (reviewed by Amit Langote).
I think either the bit abou
13 matches
Mail list logo
