Stored procedure call escape ({call ...}) support

[Lance @ Oracle]

So the thing to keep in mind is the escape syntax is there to make functions/procedures/literals which are specified in a vendor specific format able to be specified in a portable way. This has its origins in odbc

It does not address where or how you use it in your dml statement ( as the queries are still subject to what the vendor supports)



Best
Lance


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com
Sent from my iPad

On Jan 18, 2013, at 4:08 AM, Mark Rotteveel <mark at lawinegevaar.nl> wrote:

> On Thu, 17 Jan 2013 13:49:59 -0500, Lance Andersen - Oracle
> <Lance.Andersen at oracle.com> wrote:
>> What you are outlining is really more of a function vs a Stored
> Procedure
>> call.
>> 
>> The escape syntax for call is geared around Store Procedures though for
>> many backends it will work with functions.
>> 
>> In your example,  I would not think would work with many databases
> 
> It wouldn't work in Firebird either for most types of stored procedures,
> but the current escape processing in Jaybird does process it. Currently
> the
> processing of an embedded call escape will create a query that won't work,
> although I could change it so it works for the selectable types of stored
> procedures. I wanted to know whether it is allowed/expected for the call
> escape: most of the other JDBC escapes can occur anywhere in a statement
> text (where appropriate for the type of escape). If a call escape should
> only occur if it is the full statement text (ignoring whitespace and
> comments) it is easier: I can just remove part of the processing it
> currently does and simplify other parts, but otherwise I will have to fix
> it to actually work if the call escape is embedded in a larger query.
> 
> Mark