31.05.2021 22:21, Adriano dos Santos Fernandes wrote:
As the second, unrelated change, shorten EXECUTE
PROCEDURE/STATEMENT/what-else OBJECT to EXEC OBJECT and decide about
object type from context - provided it will not raise the hell in btyacc.
I do not understood what you mean.
Shorthands
On 31/05/2021 14:47, Alex Peshkoff via Firebird-devel wrote:
> On 5/31/21 4:19 PM, Adriano dos Santos Fernandes wrote:
>> Hi!
>>
>> EXECUTE PROCEDURE is full of weirdness...
>
> May be keep old syntax and add some new, not related with SQL-standard
> CALL:
>
> EXECUTE PROCEDURE [ . ]
> [ |
31.05.2021 18:34, Dmitry Yemanov wrote:
As far as I see, it's the same as EXECUTE PROCEDURE without outputs. But we already have
non-standard RETURNING added to standard I/U/D statements, so what's the difference?
Even if the majority objects this idea, we can still utilize CALL in the standard
On 5/31/21 4:19 PM, Adriano dos Santos Fernandes wrote:
Hi!
EXECUTE PROCEDURE is full of weirdness...
May be keep old syntax and add some new, not related with SQL-standard CALL:
EXECUTE PROCEDURE [ . ]
[ | ( ) ]
[ RETURNING_VALUES |
RETURNING_VALUES ( ) |
RETURNING
On 31/05/2021 12:38, Mark Rotteveel wrote:
> The problem of selectively returning columns could be solved with
> `RETURNING`, where we introduce `RETURNING ()` to signal that no columns
> need to be returned
No, please.
Adriano
Firebird-Devel mailing list, web interface at
https://lists.sourc
On 31/05/2021 12:05, Dimitry Sibiryakov wrote:
> 31.05.2021 16:59, Adriano dos Santos Fernandes wrote:
>> But then an EXECUTE PROCEDURE ignoring output will not be possible.
>
> Why? RETURNING_VALUES clause can be left as is and new branch
> "RETURNING INTO " is just added.
>
In DSQL, without
On 31/05/2021 13:34, Dmitry Yemanov wrote:
> 31.05.2021 17:49, Dimitry Sibiryakov пишет:
>> 31.05.2021 16:19, Alex Peshkoff via Firebird-devel wrote:
>>> Dimitry, can you provide standard syntax for others to compare?
>>
>> https://ronsavage.github.io/SQL/sql-2003-2.bnf.html#call%20statement
>
> A
_ Information from ESET Mail Security, version of virus signature
database 23348 (20210524) __
The message was checked by ESET Mail Security.
http://www.eset.com
__ Information from ESET Mail Security, version of virus signature
database 23386 (20210531) __
T
31.05.2021 17:49, Dimitry Sibiryakov пишет:
31.05.2021 16:19, Alex Peshkoff via Firebird-devel wrote:
Dimitry, can you provide standard syntax for others to compare?
https://ronsavage.github.io/SQL/sql-2003-2.bnf.html#call%20statement
As far as I see, it's the same as EXECUTE PROCEDURE witho
31.05.2021 18:38, Mark Rotteveel wrote:
What is the real problem you're trying to solve? The current syntax is
20+ years old, and I think this is one of the first times (if not the
first time) I hear complaints about its verbosity, or a need to
selectively obtain output columns.
Blame me ;-)
On 31-05-2021 16:59, Adriano dos Santos Fernandes wrote:
But then an EXECUTE PROCEDURE ignoring output will not be possible.
Also, EXECUTE PROCEDURE is very verbose (specially for execute ignoring
outputs, which in most languages does not even require any keyword - but
is ambiguous with our func
31.05.2021 16:59, Adriano dos Santos Fernandes wrote:
But then an EXECUTE PROCEDURE ignoring output will not be possible.
Why? RETURNING_VALUES clause can be left as is and new branch "RETURNING INTO
" is just added.
--
WBR, SD.
Firebird-Devel mailing list, web interface at
https://l
On 31/05/2021 11:39, Vlad Khorsun wrote:
> 31.05.2021 16:19, Adriano dos Santos Fernandes wrote:
>> Hi!
>>
>> EXECUTE PROCEDURE is full of weirdness, so I propose that standard SQL
>> CALL is adapted for our needs.
>>
>> EXECUTE PROCEDURE [ . ]
>> [ | ( ) ]
>> [ RETURNING_VALUES |
>>
31.05.2021 16:19, Alex Peshkoff via Firebird-devel wrote:
Dimitry, can you provide standard syntax for others to compare?
https://ronsavage.github.io/SQL/sql-2003-2.bnf.html#call%20statement
--
WBR, SD.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/list
31.05.2021 16:19, Adriano dos Santos Fernandes wrote:
Hi!
EXECUTE PROCEDURE is full of weirdness, so I propose that standard SQL
CALL is adapted for our needs.
EXECUTE PROCEDURE [ . ]
[ | ( ) ]
[ RETURNING_VALUES |
RETURNING_VALUES ( ) ]
It does not allow one to "select"
On 31/05/2021 10:50, Dimitry Sibiryakov wrote:
> 31.05.2021 15:19, Adriano dos Santos Fernandes wrote:
>> I propose that standard SQL
>> CALL is adapted for our needs.
>
> Your proposed syntax is far from standard. I see no point in using
> standard keyword with non-standard syntax.
>
Standa
On 5/31/21 4:50 PM, Dimitry Sibiryakov wrote:
31.05.2021 15:19, Adriano dos Santos Fernandes wrote:
I propose that standard SQL
CALL is adapted for our needs.
Your proposed syntax is far from standard. I see no point in using
standard keyword with non-standard syntax.
Dimitry, can you
31.05.2021 15:19, Adriano dos Santos Fernandes wrote:
I propose that standard SQL
CALL is adapted for our needs.
Your proposed syntax is far from standard. I see no point in using standard keyword
with non-standard syntax.
--
WBR, SD.
Firebird-Devel mailing list, web interface at
ht
Hi!
EXECUTE PROCEDURE is full of weirdness, so I propose that standard SQL
CALL is adapted for our needs.
EXECUTE PROCEDURE [ . ]
[ | ( ) ]
[ RETURNING_VALUES |
RETURNING_VALUES ( ) ]
It does not allow one to "select" what just it wants.
So if one changes the procedure outpu
19 matches
Mail list logo