2010/9/9 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2010/9/9 David E. Wheeler <david(at)kineticode(dot)com>:
>>> On Sep 9, 2010, at 12:12 AM, Pavel Stehule wrote:
>>>> about 2 months for full time and 2 months for partial time - is my tip
>>> Two months full or two months partial? I'll take the latter, please!
>> 2 months - basic implementation
>> 1 months - cleaning and work on commiting
>> ---- sum - 3 month ----
> And zero time spent on convincing -hackers that the design is good?
> Not likely to get committed that way.
there are lot of questions - and I am not sure if procedures
implementation can be done in one release cycle. The basic questions:
* should be special catalog for procedures or we will use pg_proc?
* how can be implemented OUT variables - the original implementation
is simple - it's just pointer, but it's not directly possible inside
postgres, because we use a MemoryContexts?
* how can be implement a CALL statement - as plan statement or as command?
* how can be implemented variables inside psql console, if we allows them?
* how can be implement an overloading of procedures - can we use for
selection OUT variables too?
* what is procedure? It's like void function, or it can return status
code like procedures in SQL/PSM (DB2)?
--- As long years a stored procedures developer, I can say, so just
minimal implementation of procedures can help with writing little bit
more readable code for functions that return more then one scalar
result. But other features can be nice too - explicit transaction
control and unbind selects. But these features are killing gun.
> regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Alvaro Herrera||Date: 2010-09-09 18:37:39|
|Subject: Re: returning multiple result sets from a stored procedure|
|Previous:||From: Robert Haas||Date: 2010-09-09 18:27:32|
|Subject: Re: [BUGS] BUG #5305: Postgres service stops when closing