From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Ahsan Hadi <ahsan(dot)hadi(at)gmail(dot)com> |
Cc: | Quan Zongliang <zongliang(dot)quan(at)postgresdata(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: enhance SPI to support EXECUTE commands |
Date: | 2020-01-04 23:05:28 |
Message-ID: | 20200104230528.is55vhgto34ac4dw@development |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Wed, Sep 18, 2019 at 05:29:52PM +0500, Ahsan Hadi wrote:
>I don't see much use for this because the documentation says that "server's
>execute command cannot be used directly within pl/pgsql function (and it is
>not needed). Within pl/pgsql you can execute update/delete commands using
>pl/pgsql EXECUTE command and get results like row_count using "get
>diagnostic".
>
>Why would somebody do what you have shown in your example in pl/pgsql? Or
>do you have a more general use-case for this enhancement?
>
Yeah, I think that's a good question - why would we need this? In fact,
the plpgsql docs explicitly say:
The PL/pgSQL EXECUTE statement is not related to the EXECUTE SQL
statement supported by the PostgreSQL server. The server's EXECUTE
statement cannot be used directly within PL/pgSQL functions (and is
not needed).
That is because all queries in plpgsql are prepared and cached
automatically, so why would we need this feature?
In any case, the patch should probably be in "waiting on author" state,
so I'll make it that way.
registrace
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-01-04 23:19:33 | Re: Commit fest manager for 2020-01 |
Previous Message | Tomas Vondra | 2020-01-04 22:52:32 | Re: Rethinking opclass member checks and dependency strength |