Re: procedure string constant is parsed at procedure create time. - Mailing list pgsql-general

From Tom Lane
Subject Re: procedure string constant is parsed at procedure create time.
Date
Msg-id 120982.1699369680@sss.pgh.pa.us
Whole thread Raw
In response to Re: procedure string constant is parsed at procedure create time.  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-general
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2023-Nov-07, jian he wrote:
>> ----2.this will have errors.

> The problem seems to be that the procedure uses a single catalog
> snapshot during execution, so the INSERT doesn't see the table that
> CREATE has made.

It looks to me like fmgr_sql does take a new snapshot per query.
The problem is that we do parse analysis of the entire function
body before we execute any of it.  So (roughly speaking) we can
cope with DML changes between statements, but not DDL changes.

At one time it was possible to argue that this was a bug, or
at least a deficiency we ought to rectify sometime.  However,
with new-style SQL functions the entire function body is
certainly parsed before execution.  So now I'd be against
changing this aspect of old-style functions: it'd mainly have
the result of widening the semantic gap between old style and
new style, which doesn't seem like a good thing.

(The verification done by check_function_bodies likewise can't
work if earlier statements make DDL changes that affect later
ones.)

As per the advice in the fine manual, use plpgsql for this
sort of task.

            regards, tom lane



pgsql-general by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: procedure string constant is parsed at procedure create time.
Next
From: Christian Ramseyer
Date:
Subject: Re: Cluster for an appliance-type deployment