On 15/08/2022 14:42, Vlad Khorsun wrote:
>
> I like the idea but not syntax. As already mentioned, there it will be
> hard for
> app\component devs to parse the whole statement looking for parameters.
> Note,
> semicolon usually mark "client" named parameters and it will be near to
> impossible
On 15/08/2022 16:20, Dimitry Sibiryakov wrote:
> I see no difference between proposed syntax and WITH except of
> definition of functions instead of derived tables in CTE part.
> What is wrong with expanding it into something like this:
>
> WITH
I prefer to not reuse a standard keyword for
On 15/08/2022 14:47, Dmitry Yemanov wrote:
> using (p1 integer = :p1, p2 varchar(255) = :p2)
> do select * from t where t.id = :p1 and t.name = :p2
I like this one.
Or replacing USING by GIVEN.
I'm not sure the parameter-less case is nice:
using
declare function ...
do
...
Adriano
Vlad Khorsun wrote 15.08.2022 19:42:
Also, I don't like 'sql' word, especially after 'execute statement' and
'execute
block'. Too much, as for me :) Syntax with 'with' instead of 'execute sql' looks
much better to me, but it is already used in CTE's, thus it seems as not the
best
choice :(
15.08.2022 20:42, Vlad Khorsun wrote:
Note, semicolon usually mark "client" named parameters
Colon, of course, not semicolon.
Sorry,
Vlad
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
15.08.2022 20:42, Vlad Khorsun wrote:
Also, I don't like 'sql' word, especially after 'execute statement'
and 'execute
block'. Too much, as for me :) Syntax with 'with' instead of 'execute
sql' looks
much better to me, but it is already used in CTE's, thus it seems as not
the best choice :(
14.08.2022 2:28, Adriano dos Santos Fernandes wrote:
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
Is there a way to get the server to send deferred messages without
having to read an additional response? Messages like the response to
op_batch_create are deferred, meaning you have to trigger a non-deferred
action to get the response.
I tried to send op_dummy to the server, but that had no
On 15-08-2022 12:47, Alex Peshkoff via Firebird-devel wrote:
On 8/13/22 14:59, Mark Rotteveel wrote:
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
On 15-08-2022 12:40, Simonov Denis via Firebird-devel wrote:
I'm talking about the fact that EXECUTE STATEMENT supports named
parameters, including those for EXECUTE BLOCK. There's even a special
query preparser for that. Those who implement client libraries will have
to do much the same. And
On 8/13/22 14:59, Mark Rotteveel wrote:
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
On 15/08/2022 07:27, Dimitry Sibiryakov wrote:
> Adriano dos Santos Fernandes wrote 15.08.2022 12:24:
>> Firebird does not have any support for client named parameters.
>
> IMessageMetadata has field for name which is currently unused. What
> else client support do you have on mind?
>
And
15.08.2022 13:24, Adriano dos Santos Fernandes пишет:
On 15/08/2022 04:16, Simonov Denis via Firebird-devel wrote:
Very good feature, reminds me of the functionality from Oracle
WITH Procedure p1 ...
AS
...
FUNCTION f1 ...
AS
...
SELECT...
Firebird does not have any support for client
Adriano dos Santos Fernandes wrote 15.08.2022 12:24:
Firebird does not have any support for client named parameters.
IMessageMetadata has field for name which is currently unused. What else
client support do you have on mind?
--
WBR, SD.
Firebird-Devel mailing list, web interface at
On 15/08/2022 04:16, Simonov Denis via Firebird-devel wrote:
>
> Very good feature, reminds me of the functionality from Oracle
>
> WITH Procedure p1 ...
> AS
> ...
> FUNCTION f1 ...
> AS
> ...
> SELECT...
>
Plus, DECLARE VAR := ?
But things are very less useful for them due to their
>There is isc_spb_rpr_par_workers. I should have been more careful
> reading the question, sorry.
Thanks. I was grep-ing for `parallel`, expecting something like
isc_spb_bkp_parallel_workers. :)
--
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/
Firebird-Devel mailing list, web
> So, I don't see what should be added to the README.parallel_features
> regarding gbak. Do you have good idea ?
A simple pointer to doc/README.gbak. Just to make sure people reading about the
parallel features in engine don't miss the gbak too.
Something like "Parallel backups and restores are
14.08.2022 2:28, 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
14.08.2022 2:28, 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
19 matches
Mail list logo
