From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: procedure string constant is parsed at procedure create time. |
Date: | 2023-11-07 15:08:00 |
Message-ID: | 120982.1699369680@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Christian Ramseyer | 2023-11-07 23:07:10 | Re: Cluster for an appliance-type deployment |
Previous Message | David G. Johnston | 2023-11-07 12:42:05 | Re: procedure string constant is parsed at procedure create time. |