On 09/16/2014 10:44 AM, Pavel Stehule wrote:
2014-09-16 9:24 GMT+02:00 Heikki Linnakangas <hlinnakan...@vmware.com>:
On 09/16/2014 10:15 AM, Pavel Stehule wrote:
Why we don't introduce a temporary functions instead?
You can already do that:
create function pg_temp.tempfunc(i int4) returns int4 as $$ begin end; $$
language plpgsql;
it looks much more like workaround than supported feature.
What do you mean? How would the temporary functions you suggest look like?
Compared to DO, you have to do extra steps to create the function, and
drop it when you're done. And you can't use them in a hot standby, because
it changes the catalogs. (although a better solution to that would be to
make it work, as well as temporary tables, but that's a much bigger
project).
Maybe we don't need any of this, you can just use temporary function. But
clearly someone though that DO statements are useful in general, because
we've had temporary functions for ages and we nevertheless added the DO
statement.
I afraid so we create little bit obscure syntaxes, without real effect and
real cost
Any new useful syntax should be clean, simple, natural and shorter than
create function ...
Sure. I think adding a RETURNS clause to the existing DO syntax would be
all of those.
and without risks a conflicts with ANSI SQL
DO is not in the standard, so no risk of conflicts there.
I prefer a typed session variables, where is not risk of SQL injection or
some performance lost. The benefit of typed server side variables can be
for wide group of users.
I don't see how session variables would help here. Sure, you could
"return" a value from the DO-block by stashing it to a session variable
and reading it out afterwards, but that's awkward.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
