Good day experts...
Question on scalar plpgsql functions stability flags (immutable, stable)
regarding how it works in sql queries.
It is clear that for immutable/stable functions with constant parameters,
query planner could/should calculate value in a parse time and use it
directly in query, o
Thank you. I'll take it.
пн, 16 окт. 2023 г. в 00:20, Ron :
> On 10/15/23 11:19, Victor Dobrovolsky wrote:
>
> [snip]
>
> The documentation states that after some executions of such functions the
> plan should become generic.
> What is a generic plan for such a
of the case-expressions
in particular.
пн, 16 окт. 2023 г. в 00:15, Tom Lane :
> Victor Dobrovolsky writes:
> > From that - "short and dirty translation" - point of view - should I
> prefer
> > to divide that
> > $$
> > Select
> > case $1
> >
First of all, thanks everyone for the answers.
вс, 15 окт. 2023 г. в 20:08, Tom Lane :
> "David G. Johnston" writes:
> > On Sunday, October 15, 2023, Victor Dobrovolsky
> > wrote:
> >> select (case when px is not null then pf = px
> >> else pf is
I understood from documentation that case expression can be
1) optimized by planner
2) may compute its subexpressions in advance, in case of presence
aggregation functions in them, for example.
The question is - how it is combined with generic prepared plans in
pl/pgsql.
How can I deduct - when us
