Re: [Firebird-devel] New statement: EXECUTE SQL

2022-08-13 Thread Adriano dos Santos Fernandes
On 13/08/2022 20:28, Adriano dos Santos Fernandes wrote:
> and it's to use with SELECT, UPDATE, DELETE and MERGE

And also INSERT and UPDATE OR INSERT...


Adriano


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


[Firebird-devel] New statement: EXECUTE SQL

2022-08-13 Thread Adriano dos Santos Fernandes
Hi!

When one starts with a DSQL command and need to adapt it to EXECUTE BLOCK
(for example to use sub routines or use a single parameter in many places),
work is difficult when there are many parameters and output fields.
Everything must be explicitly declared.

I propose new DSQL statement that improve a lot this workflow (and others
when not all power of EXECUTE BLOCK is necessary, but it's verbosity is
inevitable).

I'm calling it EXECUTE SQL, and it's to use with SELECT, UPDATE, DELETE and
MERGE, with or without RETURNING. It seats between lack of resources +
simplicity of direct SQL command and power + verbosity of EXECUTE BLOCK.

Syntax:

execute sql [ (  ) ]
[  ]
do 

Here is how it can be used:

execute sql (p1 integer = ?, p2 integer = ?)
declare function subfunc (i1 integer) returns integer
as
begin
return i1;
end

declare procedure subproc (i1 integer) returns (o1 integer)
as
begin
o1 = i1;
suspend;
end
do
select subfunc(:p1) + o1
from subproc(:p2 + ?)

Note that parameters may be declared or directly (only in the DO command)
used like now.

Output is not declared. It's inferred from the DO command.

Statement type of the DO command is returned.


Adriano
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


[Firebird-devel] Do repeated op_batch_create leak the batch?

2022-08-13 Thread Mark Rotteveel
I'm implementing batch execution in Jaybird. Looking at the code of 
rem_port::batch_create(P_BATCH_CREATE* batch, PACKET* sendL) in 
server.cpp, it looks like sending multiple op_batch_create requests for 
the same statement handle could leak a previously created batch, as it 
doesn't call statement->rsr_batch->release() before assigning a new 
batch to statement->rsr_batch.


Is my assessment correct?

Mark
--
Mark Rotteveel


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel