| 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
| 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 |