Re: [Firebird-devel] Roadmap, Planning Board, version of 4.0 snapshots
2022.03.04. 15:04 keltezéssel, Dmitry Yemanov írta: Updated, thanks. 4.0.2 already released but snapshot's version still 4.0.2. 5.0 Alpha not released in June, please update the Planning Board page. Gabor Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Windows snapshor for Firebird 5.0
No snapshots for windows in http://web.firebirdsql.org/download/snapshot_builds/win/5.0/ And the second problem. If you download the artifact https://github.com/FirebirdSQL/firebird/suites/7826192155/artifacts/330779110 and others under Windows, it does not contain default_profiler.dll Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Current value for parallel workers
> I think DBA may want a monitoring table (MON$WORKERS?) that shows how > many workers are currently active, what attachment are they bound to, > and what task (backup/sweep/etc) are they used for. Maybe some other > metrics could be added later. Sounds good to me as well. -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New statement: EXECUTE SQL
On Tue, Aug 16, 2022 at 3:48 AM Mark Rotteveel wrote:
>
> Am I reading this correctly that your proposal is to use the following
> syntax?
>
> execute sql (p1 integer, p2 varchar(50))
> do
>select * from t where t.id = :p1 and t.name = :p2
>
> So, no explicit positional parameter markers ('?')?
>
>
Not exactly. I split proposal in two:
1) Add named parameters
This will become valid (in server):
-
select *
from rdb$database
where rdb$relation_id = :relation_id or
rdb$relation_id = :relation_id
Will report a single parameter, with name RELATION_ID.
-
Unnamed parameters (question marks) will still be allowed.
-
select *
from rdb$database
where rdb$relation_id = :relation_id or
rdb$relation_id = ? or
rdb$relation_id = :relation_id
This will report parameters in order: RELATION_ID, unnamed
-
With this, EXECUTE BLOCK can be simplified and "= ?" in input parameters
becomes optional.
2) Add EXECUTE SQL (maybe with another name)
It will support named and unnamed parameters.
So, given your example, it would be valid, but this one too:
-
execute sql (p1 integer)
do
select *
from t
where t.id = :p1 and
t.name = :p2 and
t.whatever = ?
-
Explicit parameters in the argument list will be like EXECUTE BLOCK (may
use or not "= ?").
In this way we create a path that we should have already created many times
ago, to avoid clients doing server business.
Only who can want would use unnamed parameters, and since these are
top-level commands, one would not use them if their framework does not
support them.
Adriano
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Current value for parallel workers
16.08.2022 13:02, Jiří Činčura wrote: Session context variable seems to be a good fit. Monitoring table looks like overkill. I think DBA may want a monitoring table (MON$WORKERS?) that shows how many workers are currently active, what attachment are they bound to, and what task (backup/sweep/etc) are they used for. Maybe some other metrics could be added later. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Current value for parallel workers
Jiří Činčura wrote 16.08.2022 12:02: Not yet. How would you like to see it ? Monitoring table, session context variable, database_info item ? All above ? ;) Session context variable seems to be a good fit. Monitoring table looks like overkill. And database_info is inconvenient for end users. If it is set in DPB, it should be returned by getInfo(), IMHO. For symmetry. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Current value for parallel workers
>Not yet. How would you like to see it ? Monitoring table, session > context variable, > database_info item ? All above ? ;) Session context variable seems to be a good fit. Monitoring table looks like overkill. And database_info is inconvenient for end users. > Should user session be allowed to > change it ? No. -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Current value for parallel workers
16.08.2022 12:26, Jiří Činčura wrote: Hi *, Is there a way to get current value of parallel workers (from i.e. monitoring tables)? Not yet. How would you like to see it ? Monitoring table, session context variable, database_info item ? All above ? ;) Should user session be allowed to change it ? Regards, Vlad Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Current value for parallel workers
Hi *, Is there a way to get current value of parallel workers (from i.e. monitoring tables)? -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New statement: EXECUTE SQL
>Can we just have named parameters support in Firebird before this feature > so > client parser will be not needed at all?.. That would be great. :) -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New statement: EXECUTE SQL
Adriano dos Santos Fernandes wrote 16.08.2022 3:25: No, I expect that client parsers may not do unnecessary things, at least with this statement. Can we just have named parameters support in Firebird before this feature so client parser will be not needed at all?.. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] op_que_events and database shutdown
> Are aux connections closed when a database is shutdown? In that case you > should be able to detect the connection close. As I wrote in my initially, the socket is not closed. -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] op_que_events and database shutdown
On 16-08-2022 11:01, Vlad Khorsun wrote: 16.08.2022 11:26, Jiří Činčura wrote: I just want to know there's nothing on protocol level I can use to help this situation. No response. So I suppose nothing? I didn't found anything suitable. Are aux connections closed when a database is shutdown? In that case you should be able to detect the connection close. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] op_que_events and database shutdown
16.08.2022 11:26, Jiří Činčura wrote: I just want to know there's nothing on protocol level I can use to help this situation. No response. So I suppose nothing? I didn't found anything suitable. Regards, Vlad Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] op_que_events and database shutdown
> I just want to know > there's nothing on protocol level I can use to help this situation. No response. So I suppose nothing? -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New statement: EXECUTE SQL
On 15-08-2022 19: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 :( Personally, I do like the EXECUTE SQL for its explicitness, and it fits in the EXECUTE PROCEDURE and EXECUTE BLOCK naming; it is slightly a mismatch/confusing with EXECUTE STATEMENT though. An alternative could be to extend the EXECUTE BLOCK syntax for this so it has a simplified form, without a RETURNS clause. So, it has two forms: EXECUTE BLOCK [(, ...)] [RETURNS (, ...)] AS [] BEGIN [ ...] END and the simplified form EXECUTE BLOCK [(, ...)]] AS [] DO Syntactically, the simplified form could be distinguished by the DO instead of the BEGIN. Presence of the RETURNS clause with DO would raise an error (maybe easiest is to allow it in the parse.y syntax, but raise an error when its present). A downside of this is that statement recognition by clients that currently just look for EXECUTE BLOCK might break. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New statement: EXECUTE SQL
On 16-08-2022 03:25, Adriano dos Santos Fernandes wrote:
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
for, say, Delphi components to correctly preprocess statement like below:
execute sql (p1 integer = :p1)
do
select * from t where t.id = :p1 and t.name = :p2
Client parsers already need to stop at some place.
But I understand what you mean, so just read below...
You may expect after preprocessing by app it will be like:
execute sql (p1 integer = ?)
do
select * from t where t.id = :p1 and t.name = ?
but actually it will be like:
execute sql (p1 integer = ?)
do
select * from t where t.id = ? and t.name = ?
without complex re-writing of existing preprocessors.
No, I expect that client parsers may not do unnecessary things, at least
with this statement.
We may report named parameters in the right way (currently EXECUTE BLOCK
does not report then, do not know why).
For the parsers using :name syntax, that's very easy. Just detect the
new statement and do not pre-parse it.
AFAIK .NET uses @name syntax. Since that is not a Firebird valid syntax,
it should also not be difficult to detect and replace it.
So this will not be processed by client at all. It will just read
parameter names (p1, p2) from the described statement:
execute sql (p1 integer = ?)
do
select * from t where t.id = :p1 and t.name = :p2
In fact the ugly "= ?" becomes completely unnecessary and better removed
in this statement.
And it's up to us to continue allowing unnamed parameters in this
statement or not.
I think we should and people using client libraries that require named
(instead positional) parameters could just not use them.
Am I reading this correctly that your proposal is to use the following
syntax?
execute sql (p1 integer, p2 varchar(50))
do
select * from t where t.id = :p1 and t.name = :p2
So, no explicit positional parameter markers ('?')?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
