Re: Anonymous code block with parameters - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Anonymous code block with parameters
Date
Msg-id CAFj8pRAMUyk1DRrPE+Nh3BtRZv1==RTpU0Z2f_A=+sg4GmSq+Q@mail.gmail.com
Whole thread Raw
In response to Re: Anonymous code block with parameters  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers


2014-09-16 9:58 GMT+02:00 Heikki Linnakangas <hlinnakangas@vmware.com>:
On 09/16/2014 10:44 AM, Pavel Stehule wrote:
2014-09-16 9:24 GMT+02:00 Heikki Linnakangas <hlinnakangas@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?

CREATE TEMPORARY FUNCTION ...
 

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 had a "WIDTH ... " proposal on my mind
 

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.

you can use a global variables for injection values into block.

I am not against to do some simple parametrization, but some more complex work with DO statement I don't would. It is messy now, and I don't see any benefit from this area

Pavel
 

- Heikki


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Anonymous code block with parameters
Next
From: Etsuro Fujita
Date:
Subject: Re: LIMIT for UPDATE and DELETE