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?
>> 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