2014-09-16 9:58 GMT+02:00 Heikki Linnakangas <hlinnakan...@vmware.com>:
> 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? > 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 > >