Subject | Re: [Firebird-Architect] RFC: Please unify stored procedure execution |
---|---|
Author | Dmitry Kuzmenko |
Post date | 2004-12-21T09:56:24Z |
Hello, Roman!
Tuesday, December 21, 2004, 1:07:48 AM, you wrote:
RR> I see the need to unifying the way stored procedures are handled.
I agree with Vlad, here is nothing to handle. I can call
procedure with suspend as exec proc and as select * from proc,
this is my decision and I rule SQL statements in my program.
RR> a) provide a new SQL statement, for example CALL, that when applied to
for what?
RR> b) Fix the PSQL compiler to add SUSPEND before exiting the
RR> non-selectable procedure if SUSPEND is not already contained in the
RR> procedure body (in other words, automatically convert non-selectable
RR> procedure into selectable).
i hate this, really. selectable procedure must have RETURNS option.
If it does not, it could not be selectable. Of course, I add suspend
to procedures that have RETURNS and are never called by SELECT - this
is easier to debug (by calling them via select). But, I don't like when
something in computer pretends to be clever and able to decide what
I meant and what not.
Also, documentation have very clear explanation how to write
selectable and non-selectable procedures.
--
Dmitri Kouzmenko
Tuesday, December 21, 2004, 1:07:48 AM, you wrote:
RR> I see the need to unifying the way stored procedures are handled.
I agree with Vlad, here is nothing to handle. I can call
procedure with suspend as exec proc and as select * from proc,
this is my decision and I rule SQL statements in my program.
RR> a) provide a new SQL statement, for example CALL, that when applied to
for what?
RR> b) Fix the PSQL compiler to add SUSPEND before exiting the
RR> non-selectable procedure if SUSPEND is not already contained in the
RR> procedure body (in other words, automatically convert non-selectable
RR> procedure into selectable).
i hate this, really. selectable procedure must have RETURNS option.
If it does not, it could not be selectable. Of course, I add suspend
to procedures that have RETURNS and are never called by SELECT - this
is easier to debug (by calling them via select). But, I don't like when
something in computer pretends to be clever and able to decide what
I meant and what not.
Also, documentation have very clear explanation how to write
selectable and non-selectable procedures.
--
Dmitri Kouzmenko