From: | Milan Oparnica <milan(dot)opa(at)gmail(dot)com> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: PERSISTANT PREPARE (another point of view) |
Date: | 2008-07-27 23:02:09 |
Message-ID: | g6iuol$202l$1@news.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Pavel Stehule wrote:
> Hello
>
> this is near my implemenation of stored procedures - it's not far from
> your view on prepared statements. There result of any unbound select
> is directly forwarded to client - there is little bit different
> syntax, but idea is same
>
>
> create procedure foo(params)
> as $$
> begin
> select a, b, c from tab1 -- unbound select
> select ....
> end;
>
> and you can call with CALL statement. Curent implementation of SRF
> function in plpgsql sn't eficient for big results - it needs
> materialised table in memory. Pipeline Oracle's functions are better,
> but we are limited one thread architecture.
>
> regards
> Pavel Stehule
>
Yeah, this would be pretty the same.
I just didn't understand if this is already implemented in PG ?
I've tried to create a PROCEDURE in QueryTool of pgAdminIII and I get
following result:
ERROR: syntax error at or near "PROCEDURE"
LINE 1: CREATE PROCEDURE aatestubnd(refcursor, insklid integer, inda...
^
********** Error **********
ERROR: syntax error at or near "PROCEDURE"
SQL state: 42601
Character: 8
If I try with CREATE FUNCTION I get this result (as expected):
ERROR: function result type must be specified
********** Error **********
ERROR: function result type must be specified
SQL state: 42P13
Is this because of QueryTool's limitations or is this feature not yet
implemented in Postgre ?
Though, CREATE PROCEDURE should be a valid SQL 92 standard procedure.
Best regards,
Milan Oparnica
From | Date | Subject | |
---|---|---|---|
Next Message | Jean-David Beyer | 2008-07-28 00:24:28 | Re: Re: Efficiently determining the number of bits set in the contents of, a VARBIT field |
Previous Message | Milan Oparnica | 2008-07-27 22:11:25 | Re: PERSISTANT PREPARE (another point of view) |