Re: The const expression evaluation routine should always return a copy

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

In response to

Browse pgsql-hackers by date

  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