Subject | Re: [Firebird-Architect] Re: RFC: Please unify stored procedure execution |
---|---|
Author | Martijn Tonies |
Post date | 2004-12-22T09:15:21Z |
Nickolay,
FWIW, I agree to all of our points.
With regards,
Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server
Upscene Productions
http://www.upscene.com
FWIW, I agree to all of our points.
With regards,
Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server
Upscene Productions
http://www.upscene.com
> > > I agree. It would be nice to have procedure type flag
> > computed by the
> > > engine based on presence of SUSPEND statement in there.
> > > If EXECUTE PROCEDURE is called on "selectable" SP it may return
> > > resultset.
> >
> > Let me see whether I got this thing right.
> >
> > 1) RDB$PROCEDURE_TYPE is introduced and calculated by the engine
>
> Yes.
>
> > 2) Client-side EXEC PROC is described as either select or
> > execute depending on this value
>
> Yes. This way access layer may decide if it wants to hide the difference
> between executable and selectable procedures or not.
>
> > 3) Since we don't have cursor datatypes, PSQL EXEC PROC needs
> > an iteration extention (e.g. FOR EXEC PROC)
> > 4) FOR EXEC PROC is not allowed for non-suspend procedures
> > 5) PSQL simple EXEC PROC behaves like now (don't care about
> > the new type
> > value)
>
> No, I have slightly different opinion regarding EXECUTE PROCEDURE
> handling in PSQL code.
>
> 3) EXECUTE PROCEDURE remains singleton construct and works either with
> executable SP or singleton selectable SP.
> If selectable SP does not return rows or returns more than one row we
> need to handle it according to standard logic, basically raise exception
> in both cases.
>
> 4) SELECT should only work with selectable SP and should not compile if
> you attempt to use it with executable SP.
>
> 5) I do not see the special need for FOR EXECUTE PROCEDURE iteration
> construct, FOR SELECT may be used instead. But if we want it (for
> example, due to Codd's orthogonality reasons) we may add it as an alias
> to FOR SELECT and generate the same BLR as if you wrote SELECT * FROM
> <proc_name>.
>
> This way we add consistency and guard against programmer mistakes, but
> also preserve compatiblity with existing correct user code.
>
> > Dmitry
>
> Nickolay
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>