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

[Lance @ Oracle]

It is real lump to you based on whether your implementation supports a means of a function or procedure being part of a broader dml statement.  

JDBC expects it to work when it is specified on its own but does not preclude you from supporting it elsewhere if the database supports it

Hth

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 7:15 AM, "Lance @ Oracle" <lance.andersen at oracle.com> wrote:

> 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