Re: Inline non-SQL SRFs using SupportRequestSimplify

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Inline non-SQL SRFs using SupportRequestSimplify
Date: 2025-12-02 06:05:52
Message-ID: 295577.1764655552@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> ne 23. 11. 2025 v 1:45 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:
>> So after some thought I renamed inline_set_returning_function to
>> inline_function_in_from, and made a bunch of other changes in names
>> and comments to line up with that.

> I checked this patch, and I think so using the body of the
> function foo_from_bar is very confusing.

Perhaps that example could use more documentation effort ...

> More correct form should be
> RAISE EXCEPTION 'halt - should not be executed directly';

... but I don't agree with this at all. We specifically do
not guarantee that replacement via SupportRequestSimplify
will be honored, and I think the same must be true for
SupportRequestInlineInFrom. Otherwise we risk breaking
who-knows-how-many third-party tools, as well as cases
where the optimizer declines to inline (eg, because there
are volatile arguments). Besides, what's the value?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2025-12-02 06:08:23 Re: Proposal: Conflict log history table for Logical Replication
Previous Message Fujii Masao 2025-12-02 06:02:28 Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect