From: | Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: The const expression evaluation routine should always return a copy |
Date: | 2024-02-28 03:24:47 |
Message-ID: | 95d6a074-e985-49c3-9796-3f759081f8ca@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 28/2/2024 04:19, Tom Lane wrote:
> Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> writes:
>> IMO, the routine eval_const_expressions_mutator contains some stale code:
>
> I'd like to push back against the idea that eval_const_expressions
> is expected to return a freshly-copied tree. Its API specification
> contains no such claim. It's true that it appears to do that
> everywhere but here, but I think that's an implementation detail
> that callers had better not depend on. It's not hard to imagine
> someone trying to improve its performance by avoiding unnecessary
> copying.
Thanks for the explanation. I was just such a developer of extensions
who had looked into the internals of the eval_const_expressions, found a
call for a '_mutator' function, and made such a mistake :).
I agree that freeing the return node value doesn't provide a sensible
benefit because the underlying bushy tree was copied during mutation.
What's more, it makes even less sense with the selectivity context
coming shortly (I hope).
--
regards,
Andrei Lepikhov
Postgres Professional
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2024-02-28 03:50:13 | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |
Previous Message | Amit Kapila | 2024-02-28 03:19:19 | Re: Synchronizing slots from primary to standby |