Re: Anonymous code block with parameters

2014-09-16 9:58 GMT+02:00 Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>:

> On 09/16/2014 10:44 AM, Pavel Stehule wrote:
>
>> 2014-09-16 9:24 GMT+02:00 Heikki Linnakangas <hlinnakangas(at)vmware(dot)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
>
>