|Subject||Re: Java Stored Procedures|
> No, it doesn't mean that. It only means that the functionalityConsider the recent implementation of INSERT ... INTO ... RETURN.. ISC
> available in Firebird can be captured in JDBC 1.2. It can be
> extended, but it doesn't have to be.
API did not require any change to support this construction. Support
for this feature in JDBC changed the java.sql.Statement and
> Huh? We were talking about an internal engine API exportable toThen you have missed the point. The target is external procedures
> language processors. What does that have to do with IBX, et al?
written in different languages, including C++ and Delphi, not only
processors that either require p-code engine or a scripting language.
> Nobody has suggested that the load language processor interface beSorry, I though we talk about using JayBird for Java.
> backported to Firebird 1.0 or 1.5, so I don't see your point.
> Roman, the external API doesn't exist inside the engine in aOk. Then I wait for a finalized internal API.
> supportable manner. Just get used to that idea.
> Let us get this straight. You want to screw up the internalDefinitely not. Since you view my participation as an attempt to screw
> architecture of Firebird so you don't have to change your code. Is
> that the only real issue here?
things up, than I simply stop this discussion and wait until core team
presents me an interface. That's basically what I said - there is no
agreement on the API, you do not accept proposal made by me, Vlad and
Eugeney, I personally do not like your API. Since I'm not core engine
developer, I simply wait until a new API is presented. After that I
will think what is better - to support new API or to map it into the
ISC API considering the performance and the code maintainability.