I wrote:
> Oh, scratch that: I'd gotten confused about which branch I was
> working in. It does change the output as you say.
After poking at that for awhile, I decided we need a small tweak
in EXPLAIN itself to make the output consistent. See attached.
I'm now leaning against back-patching, as
On Mon, May 19, 2025 at 7:45 PM Tom Lane wrote:
> Isaac Morland writes:
> > I assume this question has an obvious negative answer, but why can't we
> > attach const declarations to the various structures that make up the plan
> > tree (at all levels, all the way down)? I know const doesn't actua
On 20/5/25 22:43, Nico Williams wrote:
[snip]
What you want is for C to have a type attribute that denotes
immutability all the way down. `const` doesn't do that. One thing that
could be done is to write a utility that creates const-all-the-way-down
clones of given types, but such a tool can't
Andres Freund writes:
> On 2025-05-20 16:18:57 -0400, Tom Lane wrote:
>> I'm curious though: what was the test case you were looking at?
> It's a modified query from our regression tests, I had added some debugging to
> find cases where the targetlists differed. I attached the extracted, somewha
I wrote:
> [ confused... ] I get the same output from that script with or
> without the patch.
Oh, scratch that: I'd gotten confused about which branch I was
working in. It does change the output as you say.
I still think it's irrelevant to view display, including pg_dump,
though. Those operat
On Mon, May 19, 2025 at 08:41:06AM -0400, Isaac Morland wrote:
> I assume this question has an obvious negative answer, but why can't we
> attach const declarations to the various structures that make up the plan
> tree (at all levels, all the way down)? I know const doesn't actually
> prevent a va
Hi,
On 2025-05-20 16:18:57 -0400, Tom Lane wrote:
> Andres Freund writes:
> >> I'm tempted to back-patch this: the plan tree damage seems harmless at
> >> present, but maybe it'd become less harmless with future fixes.
>
> > There are *some* cases where this changes the explain output, but but t
Andres Freund writes:
> Largely makes sense, the only thing I see is that the !returningLists branch
> does:
> /*
>* We still must construct a dummy result tuple type, because
> InitPlan
>* expects one (maybe should change that?).
>*/
Hi,
On 2025-05-20 13:04:46 -0400, Tom Lane wrote:
> I wrote:
> > I think we can just delete this assignment (and fix these comments).
>
> As attached.
Largely makes sense, the only thing I see is that the !returningLists branch
does:
/*
* We still must construct a
I wrote:
> I think we can just delete this assignment (and fix these comments).
As attached. I'm tempted to back-patch this: the plan tree damage
seems harmless at present, but maybe it'd become less harmless with
future fixes.
regards, tom lane
diff --git a/src/backend/
Andres Freund writes:
> Afaict the mtstate->ps.plan->targetlist assignment, and the ExecTypeFromTL(),
> ExecAssignResultTypeFromTL() before that, are completely superfluous. Am I
> missing something?
I think you are right. The two tlists are completely identical in
most cases, because of this b
Hi,
On 2025-05-20 10:59:22 -0400, Andres Freund wrote:
> On 2025-05-18 19:31:33 -0400, Tom Lane wrote:
> > While chasing down Valgrind leakage reports, I was disturbed
> > to realize that some of them arise from a case where the
> > executor scribbles on the plan tree it's given, which it is
> > a
Hi,
On 2025-05-18 19:31:33 -0400, Tom Lane wrote:
> While chasing down Valgrind leakage reports, I was disturbed
> to realize that some of them arise from a case where the
> executor scribbles on the plan tree it's given, which it is
> absolutely not supposed to do:
>
> /*
> * In
On 19/5/25 16:45, Tom Lane wrote:
[snip]
For one thing, I'm not sure how to teach the compiler that casting
"Query *" to "ConstQuery *" is okay but vice versa isn't.
Does C++ have a better story in this area?
Hi,
A C++ compiler *does* enforce "const correctness" (for examples
see, for ex
Isaac Morland writes:
> I assume this question has an obvious negative answer, but why can't we
> attach const declarations to the various structures that make up the plan
> tree (at all levels, all the way down)? I know const doesn't actually
> prevent a value from changing, but at least the comp
On Mon, May 19, 2025 at 10:35 AM Tom Lane wrote:
> I proposed a possible way to test for this at [1]. I was intending to
> get around to that sooner or later, but the urgency of the matter just
> went up in my eyes...
Ah, right, I actually read that thread but had forgotten about it. I
don't kno
Robert Haas writes:
> On Sun, May 18, 2025 at 7:31 PM Tom Lane wrote:
>> While chasing down Valgrind leakage reports, I was disturbed
>> to realize that some of them arise from a case where the
>> executor scribbles on the plan tree it's given, which it is
>> absolutely not supposed to do:
> Is
On Mon, 19 May 2025 at 08:35, Robert Haas wrote:
> On Sun, May 18, 2025 at 7:31 PM Tom Lane wrote:
> > While chasing down Valgrind leakage reports, I was disturbed
> > to realize that some of them arise from a case where the
> > executor scribbles on the plan tree it's given, which it is
> > abs
On Sun, May 18, 2025 at 7:31 PM Tom Lane wrote:
> While chasing down Valgrind leakage reports, I was disturbed
> to realize that some of them arise from a case where the
> executor scribbles on the plan tree it's given, which it is
> absolutely not supposed to do:
>
> /*
> * Initi
While chasing down Valgrind leakage reports, I was disturbed
to realize that some of them arise from a case where the
executor scribbles on the plan tree it's given, which it is
absolutely not supposed to do:
/*
* Initialize result tuple slot and assign its rowtype using the first
20 matches
Mail list logo
