On 31/8/2025 03:03, Richard Guo wrote:
> On Sun, Aug 31, 2025 at 9:50 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:
>> On Sun, Aug 31, 2025 at 2:51 AM Richard Guo <guofenglinux@gmail.com> wrote:
>>> I think it's better to push this patch sooner rather than later, as
>>> multiple people have encountered the issue in different ways. I'll go
>>> ahead and push 0001 from my patch set shortly.
>
>> I see. You're much farther than I'm. Please, go ahead pushing this.
>
> Done.
Hmm, is this enough? As I see, it is a typical pattern: after
deserialisation by the stringToNode function, Postgres attempts to call
eval_const_expressions. See, for example, RelationGetIndexExpressions.
That seems strange, because who knows what the entry No.1 is and how
constant evaluation over this relation influences the expression tree.
Perhaps it would be beneficial to refactor all this logic? Maybe go
further and, before storing any relation constraint to the system
catalogue, replace varno with something like 'UNDEF_VAR (-5)'?
I thought about why it was designed that way. Commit eabc714 shows that
at that time, the eval_const_expressions didn't touch PlannerInfo data
at all. Currently, it requires query structures in some cases,
particularly in prosupport functions, which necessitates having correct
relation references.
--
regards, Andrei Lepikhov
