From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Kalyanov Dmitry <kalyanov(dot)dmitry(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Anonymous code block with parameters |
Date: | 2014-09-16 07:58:18 |
Message-ID: | 5417ED9A.5040202@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
>> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2014-09-16 08:01:18 | Re: Anonymous code block with parameters |
Previous Message | Craig Ringer | 2014-09-16 07:57:49 | Re: Anonymous code block with parameters |