It is probably not widely used nor necessary to allow single SP
to be called in either of two ways (and I personally do not insist
on preserving such feature), otoh it IS documented.

(It was useful in the past when EXECUTE PROCEDURE command
did not work correctly, and the workaround was to add SUSPEND
and call all procedures as selectable)

Table from IB4 - IB6 documentation:
--------
The following table summarizes the behavior of SUSPEND, EXIT, and END.

Select procedure - SUSPEND
* Suspends execution of procedure until next FETCH is issued
* Returns output values

Select procedure - EXIT
* Jumps to final END

Select procedure - END
* Returns control to application
* Sets SQLCODE to 100 (end of record stream)

Executable procedure - SUSPEND
* Jumps to final END
* Not recommended

Executable procedure - EXIT
* Jumps to final END

Executable procedure - END
* Returns values
* Returns control to application
-------------------

Ivan

----- Original Message -----
From: "Jim Starkey" <jas@...>
To: <Firebird-Architect@yahoogroups.com>
Sent: Wednesday, December 22, 2004 4:48 PM
Subject: [Firebird-Architect] Legacy Behavior


> Dmitry Yemanov wrote:
>
> >"Geoff Worboys" <geoff@...> wrote:
> >
> >>Personnally I would also like an exception to be thrown when
> >>a procedure is called with an incompatible method. This way,
> >>as a developer, I get told when I've stuffed up. Possibly
> >>this is undesireable for backwards compatibility reasons.
> >>
> >
> >Now we have:
> >
> >CREATE PROCEDURE P RETURNS (X INT)
> >BEGIN
> > X = 0;
> > SUSPEND;
> >END
> >
> >And by design it has two compatible execution methods. And we must preserve
> >it, not because it's a legacy stuff, but because it's a useful feature,
> >IMHO.
> >
> >
> I don't particularly care about this case, but it raises a question
> worth discussing, which is what legacy behaviors should be preserved?
>
> Programs that use advertised features for the purpose documented should
> be respected at almost all costs. If we make a mistake in language or
> API design, we should live with it, both out of respect for our users
> and as a reminder to think more and better next time. At the other end
> of the spectrum are people who take advantage of implementation
> artifacts, for example, the nature of handles. I don't have the
> slightest qualm about yanking the rug out from underneath these guys.
> Any system are arbitrary artifact and every system has to evolve.
> Freezing everything freezes progress. If somebody builds in a
> dependency on an artifact due to bad taste, bad planning, a lack of
> knowledge, bad toilet training, or whatever, that's too bad. His
> application will break over an upgrade and hopefully he'll learn
> something from it.
>
> I prefer not to give people rope to hang themselves. Unfortunately, the
> Borland guys didn't have this philosophy. The two types of procedures
> should not have been comingled. Somebody had the beastly clever idea
> that a single syntax and implementation could painlessly server two
> masters. Cute. But now we have the pain.
>
> It is certainly possible to write a procedure that does something
> meaningful if invoked in either environment, though it is unlikely that
> anyone has actually done this. The fact that the procedure can't tell
> which way it was invoked is kind of a showstopper. But if someone did,
> he either knew or should have known that this was entirely too cute to
> work in the long run. And if not, next time he'll know.
>
> Simply put, we should not let the possible existence of a utter dolt
> impede progress.
>
> --
>
> Jim Starkey
> Netfrastructure, Inc.
> 978 526-1376