Skip site navigation (1) Skip section navigation (2)

Re: PERSISTANT PREPARE (another point of view)

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$ (view raw, whole thread or download thread mbox)
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

In response to


pgsql-sql by date

Next:From: Jean-David BeyerDate: 2008-07-28 00:24:28
Subject: Re: Re: Efficiently determining the number of bits set in the contents of, a VARBIT field
Previous:From: Milan OparnicaDate: 2008-07-27 22:11:25
Subject: Re: PERSISTANT PREPARE (another point of view)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group