Re: [Firebird-devel] Deprecations
On Thu, 27 May 2021 08:39:58 -0300, Adriano dos Santos Fernandes wrote: > On 27/05/2021 04:29, Virgo Pärna via Firebird-devel wrote: >> >> At same time UDF is still faster than UDR/function. I did some > > UDR will always be slower than UDF, after all UDF is insecure (does not > validate all things to be secure). > > But UDR could be improved. It has a thin layer AS PSQL functions, where > it checks input and output parameters constraints and defaults. > > That layer, if implemented different, could make things faster than now. > I understand. I just posted it to show, that UDF does still have some advantages. And since UDF is still available in 4.0, then it is not issue for when eventually switching tothat version. >> Actually, one conversion could be done with: >> CAST((CAST(FIELD_WITH_UTC_TIME||'UTC' AS TIMESTAMP WITH TIME ZONE) AT >> LOCAL) AS >> TIMESTAMP) >> But it is ~4.5 times slower than UDF. >> > > You can SET TIME ZONE 'UTC'; Maybe. I need to do comparisions in queries between date stored to TIMESTAMP field bye local timezone and UTC timestamps (do those timestamps fall into date period). And currently I'm using conversions on both directions in same query. Although those can be rewritten so, that only on type of conversion is used. And then there is always issue of slowness of using this kind of CAST to convert. -- Virgo Pärna virgo.pa...@mail.ee Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
On 27/05/2021 08:48, Omacht András wrote: > Adriano, > > can you tell me what are the extra jobs that make calling through a function > such a significant slowdown in other cases? > > It will be difficult to change from UDF to function if the runtime is doubled > in such a simple case as it is in the fourth case compared to the fifth. > > And, although I haven’t tested UDF yet, there were no good numbers about it > before either (slower than PSQL(?)) : > https://sourceforge.net/p/firebird/mailman/message/36706890/ > When you have expressions like 'constant' versus lpad(extract(...)) || lpad(extract(...)) you're comparing different things, the second case certainly being much slower. The same when you have an expression inside a function versus the same expression inlined in SQL. Firebird SQL/PSQL optimizes very few things in relation to statements/expressions and it executes interpreted. In relation to UDR, it's a layer that has a cost to be traversed many times. But UDR implementation (user code) could be done in different ways, and some ways are faster (pre-compute buffer positions in prepare time versus execution time). UDR is flexible. Not everyone needs a routine fast enough to be called million of times and may do simple implementations. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
Adriano, can you tell me what are the extra jobs that make calling through a function such a significant slowdown in other cases? It will be difficult to change from UDF to function if the runtime is doubled in such a simple case as it is in the fourth case compared to the fifth. And, although I haven’t tested UDF yet, there were no good numbers about it before either (slower than PSQL(?)) : https://sourceforge.net/p/firebird/mailman/message/36706890/ András -Original Message- From: Adriano dos Santos Fernandes [mailto:adrian...@gmail.com] Sent: Thursday, May 27, 2021 1:33 PM To: firebird-devel@lists.sourceforge.net Subject: Re: [Firebird-devel] Deprecations On 27/05/2021 07:49, Omacht András wrote: > Hi Virgo and all! > > > > I also did some tests on 3.0.8.33468 > > > > I had a table with 2.8 million records. I tested with its one of the > date (not timestamp) fields. > > > > Case 1.: UDF call > > DECLARE EXTERNAL FUNCTION TO_CHAR > > TIMESTAMP, > > CSTRING(50) > > RETURNS CSTRING(50) FREE_IT > > ENTRY_POINT 'to_char' MODULE_NAME 'UDF3s'; > > > > select count(to_char(date_field, '.MM.DD.')) from table > > > > Case 2.: Function UDF call inside > > create function case_2 (datum date) > > returns varchar(50) > > as > > begin > > return to_char(datum, '.MM.DD.'); > > end > > > > select count(case_2(date_field)) from table > > > > Case 3.: Function fix string return > > create function case_3(datum date) > > returns varchar(50) > > as > > begin > > return '2021.05.27.'; > > end > > > > select count(case_3(date_field)) from table > > > > Case 4.: Function extract inside > > create function case_4 (datum date) > > returns varchar(50) > > as > > begin > > return extract(year from datum) || '.' || > > lpad(extract(month from datum), 2, '0') || '.' || > > lpad(extract(day from datum), 2, '0') || '.'; > > end > > > > select count(case_4(date_field)) from table > > > > Case 5.: Extract in select > > select count(extract(year from date_field) || '.' || > > lpad(extract(month from date_field), 2, '0') || '.' || > > lpad(extract(day from date_field), 2, '0') || '.') from table > > > The issues that arise: > > - Why is the second case twice as slow as the first? > First case you call UDF. Second case you call PSQL + UDF. > - Why is the fourth case twice as slow as the fifth? > You do the same work as the fifth case plus a PSQL call. > - If the function call is slow, then why is the third case > not as slow as the second and fourth? Why is it as fast as the first and > fifth? > In the third case you just do a function call and return a constant, not doing the extra work you do in the others cases. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
On 27/05/2021 04:29, Virgo Pärna via Firebird-devel wrote: > On Thu, 20 May 2021 11:45:22 +, Omacht András > wrote: >> UDF has been a compromise for us from the beginning (since IB 6.0 or maybe >> 5.5). If it is possible, we don’t want to depend on things outside of the >> database because it is only a problem to have to ask the customers for any >> extras for the programs to work. >> > > At same time UDF is still faster than UDR/function. I did some > testing with Firebird 3.0.7 ja 4.0.0RC1. I have UDF with three > functions, one of which can be rewritten as PSQL function. Results, when > used in where condition were: > UDF: ~10 sec > UDR/PSQL Function: ~15 sec (UDR and PSQL function had no practical speed > difference). > PSQL SP: ~19 sec > UDR will always be slower than UDF, after all UDF is insecure (does not validate all things to be secure). But UDR could be improved. It has a thin layer AS PSQL functions, where it checks input and output parameters constraints and defaults. That layer, if implemented different, could make things faster than now. > For the other two functions it would be nice, if Firebrid 4.0 > could do timezone conversion for TIMESTAMP WITHOUT TIMEZONE type. > Existing database has some fields, that contain timestamps in UTC time, > but some querys require converting it to local timezone (and some > reverse). And since developement enviroment does not have data type for > time wiht timezone, converting to TIMESTAMP WITH TIMEZONE is not > possible. > > Actually, one conversion could be done with: > CAST((CAST(FIELD_WITH_UTC_TIME||'UTC' AS TIMESTAMP WITH TIME ZONE) AT LOCAL) > AS > TIMESTAMP) > But it is ~4.5 times slower than UDF. > You can SET TIME ZONE 'UTC'; Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
On 27/05/2021 07:49, Omacht András wrote: > Hi Virgo and all! > > > > I also did some tests on 3.0.8.33468 > > > > I had a table with 2.8 million records. I tested with its one of the > date (not timestamp) fields. > > > > Case 1.: UDF call > > DECLARE EXTERNAL FUNCTION TO_CHAR > > TIMESTAMP, > > CSTRING(50) > > RETURNS CSTRING(50) FREE_IT > > ENTRY_POINT 'to_char' MODULE_NAME 'UDF3s'; > > > > select count(to_char(date_field, '.MM.DD.')) from table > > > > Case 2.: Function UDF call inside > > create function case_2 (datum date) > > returns varchar(50) > > as > > begin > > return to_char(datum, '.MM.DD.'); > > end > > > > select count(case_2(date_field)) from table > > > > Case 3.: Function fix string return > > create function case_3(datum date) > > returns varchar(50) > > as > > begin > > return '2021.05.27.'; > > end > > > > select count(case_3(date_field)) from table > > > > Case 4.: Function extract inside > > create function case_4 (datum date) > > returns varchar(50) > > as > > begin > > return extract(year from datum) || '.' || > > lpad(extract(month from datum), 2, '0') || '.' || > > lpad(extract(day from datum), 2, '0') || '.'; > > end > > > > select count(case_4(date_field)) from table > > > > Case 5.: Extract in select > > select count(extract(year from date_field) || '.' || > > lpad(extract(month from date_field), 2, '0') || '.' || > > lpad(extract(day from date_field), 2, '0') || '.') from table > > > The issues that arise: > > - Why is the second case twice as slow as the first? > First case you call UDF. Second case you call PSQL + UDF. > - Why is the fourth case twice as slow as the fifth? > You do the same work as the fifth case plus a PSQL call. > - If the function call is slow, then why is the third case not > as slow as the second and fourth? Why is it as fast as the first and fifth? > In the third case you just do a function call and return a constant, not doing the extra work you do in the others cases. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
Hi Virgo and all! I also did some tests on 3.0.8.33468 I had a table with 2.8 million records. I tested with its one of the date (not timestamp) fields. Case 1.: UDF call DECLARE EXTERNAL FUNCTION TO_CHAR TIMESTAMP, CSTRING(50) RETURNS CSTRING(50) FREE_IT ENTRY_POINT 'to_char' MODULE_NAME 'UDF3s'; select count(to_char(date_field, '.MM.DD.')) from table Case 2.: Function UDF call inside create function case_2 (datum date) returns varchar(50) as begin return to_char(datum, '.MM.DD.'); end select count(case_2(date_field)) from table Case 3.: Function fix string return create function case_3(datum date) returns varchar(50) as begin return '2021.05.27.'; end select count(case_3(date_field)) from table Case 4.: Function extract inside create function case_4 (datum date) returns varchar(50) as begin return extract(year from datum) || '.' || lpad(extract(month from datum), 2, '0') || '.' || lpad(extract(day from datum), 2, '0') || '.'; end select count(case_4(date_field)) from table Case 5.: Extract in select select count(extract(year from date_field) || '.' || lpad(extract(month from date_field), 2, '0') || '.' || lpad(extract(day from date_field), 2, '0') || '.') from table I ran each case ten times. Here are the results: UDF call Function UDF call inside Function fix string return Function extract inside Extract in select AVG: 10,97 20,94 11 21,87 11,91 MIN: 10,2 19,5 9,7 20,7 11,1 MAX: 12,1 22,7 12,2 23,1 13,3 The issues that arise: - Why is the second case twice as slow as the first? - Why is the fourth case twice as slow as the fifth? - If the function call is slow, then why is the third case not as slow as the second and fourth? Why is it as fast as the first and fifth? András -Original Message- From: Virgo Pärna via Firebird-devel [mailto:firebird-devel@lists.sourceforge.net] Sent: Thursday, May 27, 2021 9:29 AM To: firebird-devel@lists.sourceforge.net Cc: Virgo Pärna Subject: Re: [Firebird-devel] Deprecations On Thu, 20 May 2021 11:45:22 +, Omacht András mailto:omacht.and...@libra.hu>> wrote: > UDF has been a compromise for us from the beginning (since IB 6.0 or maybe > 5.5). If it is possible, we don’t want to depend on things outside of the > database because it is only a problem to have to ask the customers for any > extras for the programs to work. > At same time UDF is still faster than UDR/function. I did some testing with Firebird 3.0.7 ja 4.0.0RC1. I have UDF with three functions, one of which can be rewritten as PSQL function. Results, when used in where condition were: UDF: ~10 sec UDR/PSQL Function: ~15 sec (UDR and PSQL function had no practical speed difference). PSQL SP: ~19 sec For the other two functions it would be nice, if Firebrid 4.0 could do timezone conversion for TIMESTAMP WITHOUT TIMEZONE type. Existing database has some fields, that contain timestamps in UTC time, but some querys require converting it to local timezone (and some reverse). And since developement enviroment does not have data type for time wiht timezone, converting to TIMESTAMP WITH TIMEZONE is not possible. Actually, one conversion could be done with: CAST((CAST(FIELD_WITH_UTC_TIME||'UTC' AS TIMESTAMP WITH TIME ZONE) AT LOCAL) AS TIMESTAMP) But it is ~4.5 times slower than UDF. -- Virgo Pärna virgo.pa...@mail.ee<mailto:virgo.pa...@mail.ee> Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
On Thu, 20 May 2021 11:45:22 +, Omacht András wrote: > UDF has been a compromise for us from the beginning (since IB 6.0 or maybe > 5.5). If it is possible, we don’t want to depend on things outside of the > database because it is only a problem to have to ask the customers for any > extras for the programs to work. > At same time UDF is still faster than UDR/function. I did some testing with Firebird 3.0.7 ja 4.0.0RC1. I have UDF with three functions, one of which can be rewritten as PSQL function. Results, when used in where condition were: UDF: ~10 sec UDR/PSQL Function: ~15 sec (UDR and PSQL function had no practical speed difference). PSQL SP: ~19 sec For the other two functions it would be nice, if Firebrid 4.0 could do timezone conversion for TIMESTAMP WITHOUT TIMEZONE type. Existing database has some fields, that contain timestamps in UTC time, but some querys require converting it to local timezone (and some reverse). And since developement enviroment does not have data type for time wiht timezone, converting to TIMESTAMP WITH TIMEZONE is not possible. Actually, one conversion could be done with: CAST((CAST(FIELD_WITH_UTC_TIME||'UTC' AS TIMESTAMP WITH TIME ZONE) AT LOCAL) AS TIMESTAMP) But it is ~4.5 times slower than UDF. -- Virgo Pärna virgo.pa...@mail.ee Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
UDF has been a compromise for us from the beginning (since IB 6.0 or maybe 5.5). If it is possible, we don’t want to depend on things outside of the database because it is only a problem to have to ask the customers for any extras for the programs to work. András -Original Message- From: Mark Rotteveel [mailto:m...@lawinegevaar.nl] Sent: Thursday, May 20, 2021 10:29 AM To: firebird-devel@lists.sourceforge.net Subject: Re: [Firebird-devel] Deprecations On 2021-05-20 08:28, Omacht András wrote: > Mark: Yes, that could be good, but it’s not even in 4.0, so (one day) > we wouldn’t be able to switch to 5.0 by rewriting these calls first. > For the time being, the original plan remains: writing a function, > replacing udf calls with it ... Or rewrite such UDFs to UDRs and use that. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
On 2021-05-20 08:28, Omacht András wrote: Mark: Yes, that could be good, but it’s not even in 4.0, so (one day) we wouldn’t be able to switch to 5.0 by rewriting these calls first. For the time being, the original plan remains: writing a function, replacing udf calls with it ... Or rewrite such UDFs to UDRs and use that. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
Hi!
Mark: Yes, that could be good, but it’s not even in 4.0, so (one day) we
wouldn’t be able to switch to 5.0 by rewriting these calls first.
For the time being, the original plan remains: writing a function, replacing
udf calls with it ...
SD: If you have a single user interface and the message appears on it right
away, it's of course worth formatting the output there. In our case, it often
happens that the process does not leave the database when the message is
generated. Dates must be saved as part of a text.
András
-Original Message-
From: Mark Rotteveel [mailto:m...@lawinegevaar.nl]
Sent: Wednesday, May 19, 2021 8:04 PM
To: firebird-devel@lists.sourceforge.net
Subject: Re: [Firebird-devel] Deprecations
On 2021-05-19 19:40, Omacht András wrote:
> Hi!
>
> Since Firebird 2.5, we have been able to replace almost all UDFs with
> built-in functions.
>
> There is only one left (it’s the Highlander :)) : formatting dates and
> timestamps to readable format for hungarian people:
>
> -- Hungarian format
>
> select to_char(cast('TODAY' as date), '.MM.DD') from rdb$database
>
> -- 2021.05.19
>
> -- English format
>
> select to_char(cast('TODAY' as date), 'DD/MM/') from rdb$database
>
> -- 19/05/2021
>
> -- Year + month
>
> select to_char(cast('TODAY' as date), 'YY/MM') from rdb$database
>
> -- 21/05
>
> -- Short hungarian format
>
> select to_char(cast('2001.5.7' as date), 'YY.MM.DD') from rdb$database
>
>
> -- 01.05.07
>
> -- Hungarian timestamp format
>
> select to_char(cast('NOW' as timestamp), '.MM.DD hh:mm:ss') from
> rdb$database
>
> -- 2021.05.19 19:05:46
>
> etc.
>
> If anyone has an idea of what can be used instead, I would greatly
> appreciate it.
>
> Of course, a built-in function would be best, but please, this should
> not be the suggestion:
The following should be a SQL standard replacement to format dates (and parse
from a specific format):
https://github.com/FirebirdSQL/firebird/issues/2388; not implemented yet, nor
actually planned for a version.
Mark
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
On 19/05/2021 16:00, Dmitry Yemanov wrote: > 19.05.2021 13:32, Adriano dos Santos Fernandes wrote: >> >> v4 is not yet released. We may deprecate QLI in v4 already and remove in >> master. > > If it's just a matter of adding a paragraph to the release notes, then I > may agree to deprecate QLI in v4. > I have added a doc. issue https://github.com/FirebirdSQL/firebird-documentation/issues/152 Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
On 19/05/2021 16:02, Dmitry Yemanov wrote: > 19.05.2021 14:40, Mark Rotteveel wrote: >> >> Dialect 1 was already deprecated with InterBase 6.0. I think people >> will continue to use dialect 1 as long as Firebird supports it, though >> to be honest, I would guess that most users of dialect 1 aren't even >> on recent versions of Firebird. We should just bite the bullet now and >> remove support. > > Good point. Dialect 3 migration requires significant efforts and perhaps > users will never do that unless really forced to. > We may start just disabling it (maintaining it in the code as now, but not allowing to use it). Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
19.05.2021 19:40, Omacht András wrote:
If anyone has an idea of what can be used instead, I would greatly appreciate
it.
You can rewrite the UDF into UDR function.
but please, this should not be the suggestion:
select extract(year from cast('NOW' as timestamp)) || '.' ||
lpad(extract(month from cast('NOW' as timestamp)), 2, '0') || '.' ||
lpad(extract(day from cast('NOW' as timestamp)), 2, '0') || ' ' ||
lpad(extract(hour from cast('NOW' as timestamp)), 2, '0') || ':' ||
lpad(extract(minute from cast('NOW' as timestamp)), 2, '0') || ':' ||
lpad(extract(second from cast('NOW' as timestamp)), 2, '0')
from rdb$database
Why not if it is hidden inside of SQL function.
My opinion is that formatting must be done ONLY on user workstation because only there
it can use user's system settings.
--
WBR, SD.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
19.05.2021 14:40, Mark Rotteveel wrote: Dialect 1 was already deprecated with InterBase 6.0. I think people will continue to use dialect 1 as long as Firebird supports it, though to be honest, I would guess that most users of dialect 1 aren't even on recent versions of Firebird. We should just bite the bullet now and remove support. Good point. Dialect 3 migration requires significant efforts and perhaps users will never do that unless really forced to. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
19.05.2021 13:32, Adriano dos Santos Fernandes wrote: v4 is not yet released. We may deprecate QLI in v4 already and remove in master. If it's just a matter of adding a paragraph to the release notes, then I may agree to deprecate QLI in v4. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
On 2021-05-19 18:33, Nils Bödeker wrote: Hello as user opinion (sorry) We still using UDFs. Own written and external like this one http://freeadhocudf.org [1] For us, UDF support should be still in FB 5. I'd recommend rewriting your own UDFs to UDRs, the replacement feature for UDFs. As to freeadhocudf, could you tell us which functions specifically you're using? Mark Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
On 2021-05-19 19:40, Omacht András wrote:
Hi!
Since Firebird 2.5, we have been able to replace almost all UDFs with
built-in functions.
There is only one left (it’s the Highlander :)) : formatting dates
and timestamps to readable format for hungarian people:
-- Hungarian format
select to_char(cast('TODAY' as date), '.MM.DD') from rdb$database
-- 2021.05.19
-- English format
select to_char(cast('TODAY' as date), 'DD/MM/') from rdb$database
-- 19/05/2021
-- Year + month
select to_char(cast('TODAY' as date), 'YY/MM') from rdb$database
-- 21/05
-- Short hungarian format
select to_char(cast('2001.5.7' as date), 'YY.MM.DD') from rdb$database
-- 01.05.07
-- Hungarian timestamp format
select to_char(cast('NOW' as timestamp), '.MM.DD hh:mm:ss') from
rdb$database
-- 2021.05.19 19:05:46
etc.
If anyone has an idea of what can be used instead, I would greatly
appreciate it.
Of course, a built-in function would be best, but please, this should
not be the suggestion:
The following should be a SQL standard replacement to format dates (and
parse from a specific format):
https://github.com/FirebirdSQL/firebird/issues/2388; not implemented
yet, nor actually planned for a version.
Mark
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
Hi!
Since Firebird 2.5, we have been able to replace almost all UDFs with built-in
functions.
There is only one left (it’s the Highlander :)) : formatting dates and
timestamps to readable format for hungarian people:
-- Hungarian format
select to_char(cast('TODAY' as date), '.MM.DD') from rdb$database
-- 2021.05.19
-- English format
select to_char(cast('TODAY' as date), 'DD/MM/') from rdb$database
-- 19/05/2021
-- Year + month
select to_char(cast('TODAY' as date), 'YY/MM') from rdb$database
-- 21/05
-- Short hungarian format
select to_char(cast('2001.5.7' as date), 'YY.MM.DD') from rdb$database
-- 01.05.07
-- Hungarian timestamp format
select to_char(cast('NOW' as timestamp), '.MM.DD hh:mm:ss') from
rdb$database
-- 2021.05.19 19:05:46
etc.
If anyone has an idea of what can be used instead, I would greatly appreciate
it.
Of course, a built-in function would be best, but please, this should not be
the suggestion:
select extract(year from cast('NOW' as timestamp)) || '.' ||
lpad(extract(month from cast('NOW' as timestamp)), 2, '0') || '.' ||
lpad(extract(day from cast('NOW' as timestamp)), 2, '0') || ' ' ||
lpad(extract(hour from cast('NOW' as timestamp)), 2, '0') || ':' ||
lpad(extract(minute from cast('NOW' as timestamp)), 2, '0') || ':' ||
lpad(extract(second from cast('NOW' as timestamp)), 2, '0')
from rdb$database
:)
András
From: Nils Bödeker [mailto:nilsboede...@t-online.de]
Sent: Wednesday, May 19, 2021 6:34 PM
To: For discussion among Firebird Developers
Subject: Re: [Firebird-devel] Deprecations
Hello
as user opinion (sorry)
We still using UDFs.
Own written and external like this one
http://freeadhocudf.org<http://freeadhocudf.org/>
For us, UDF support should be still in FB 5.
With best regards
Nils Bödeker
Am 18.05.2021 um 23:44 schrieb Adriano dos Santos Fernandes
mailto:adrian...@gmail.com>>:
Hi!
UDF was been deprecated in FB 4.
Could we remove them from master for v5?
Also QLI, I believe nobody uses it and there should be no good reason to
maintain it.
I know TCS uses it, so it should be changed.
Adriano
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
__ Information from ESET Mail Security, version of virus signature
database 23322 (20210519) __
The message was checked by ESET Mail Security.
http://www.eset.com
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
Hello as user opinion (sorry) We still using UDFs. Own written and external like this one http://freeadhocudf.org For us, UDF support should be still in FB 5. With best regards Nils Bödeker > > Am 18.05.2021 um 23:44 schrieb Adriano dos Santos Fernandes > : > > Hi! > > UDF was been deprecated in FB 4. > > Could we remove them from master for v5? > > Also QLI, I believe nobody uses it and there should be no good reason to > maintain it. > > I know TCS uses it, so it should be changed. > > > Adriano > > > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
On 2021-05-19 11:49, Dmitry Yemanov wrote: 19.05.2021 12:27, Alex Peshkoff via Firebird-devel wrote: I have the same question about dialect 1 A few years ago it was discussed but people continued (at least continued that time) to use it... Same as item 1 above. We can do it now, but perhaps better to wait a bit. Dialect 1 was already deprecated with InterBase 6.0. I think people will continue to use dialect 1 as long as Firebird supports it, though to be honest, I would guess that most users of dialect 1 aren't even on recent versions of Firebird. We should just bite the bullet now and remove support. Mark Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
On 2021-05-19 12:35, Adriano dos Santos Fernandes wrote: On 19/05/2021 06:27, Alex Peshkoff via Firebird-devel wrote: Let me also add suggest gsec and related services - was deprecated in fb3. I'll not be strongly against, as I (and TCS) could probably adapt, but I always used it to add SYSDBA to security database before run TCS. What's the alternative? Connect to employee database and create an user? If yes, the necessity to have a database to connect always looked hack for me. You can create a local connection to the security database directly. Mark Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
On 19/05/2021 07:38, Dimitry Sibiryakov wrote: > 19.05.2021 12:36, Adriano dos Santos Fernandes wrote: >>> Most likely no because of differences in BLR. >>> >> What differences? > > Whichever will be introduced in v5. > QLI already is unmaintained, it does not even support v4 BLR extensions. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
19.05.2021 12:36, Adriano dos Santos Fernandes wrote: Most likely no because of differences in BLR. What differences? Whichever will be introduced in v5. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
19.05.2021 12:35, Adriano dos Santos Fernandes wrote: Connect to employee database and create an user? Connect to the security database and create user. You cannot create users without security database (with gsec as well). -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
On 19/05/2021 07:35, Dimitry Sibiryakov wrote: > 19.05.2021 12:32, Adriano dos Santos Fernandes wrote: >> in the worst >> cases, people could get it from v4 and use with v5. > > Most likely no because of differences in BLR. > What differences? Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
On 19/05/2021 06:27, Alex Peshkoff via Firebird-devel wrote: > > Let me also add suggest gsec and related services - was deprecated in fb3. > I'll not be strongly against, as I (and TCS) could probably adapt, but I always used it to add SYSDBA to security database before run TCS. What's the alternative? Connect to employee database and create an user? If yes, the necessity to have a database to connect always looked hack for me. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
19.05.2021 12:32, Adriano dos Santos Fernandes wrote: in the worst cases, people could get it from v4 and use with v5. Most likely no because of differences in BLR. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
On 19/05/2021 06:49, Dmitry Yemanov wrote: > 19.05.2021 12:27, Alex Peshkoff via Firebird-devel wrote: >>> >>> UDF was been deprecated in FB 4. >>> >>> Could we remove them from master for v5? >> >> Doubt that. UDF is too actively used feature, lot of users will not be >> happy. > > Generally, it's OK to remove already deprecated features in the next > major release. However, if we speak about a fast release, then maybe > removing would be an overkill and it should happen only in v6 -- to give > users more than one year to adjust their logic. > We may live with that. >>> Also QLI, I believe nobody uses it and there should be no good reason to >>> maintain it. >>> >>> I know TCS uses it, so it should be changed. >> >> Good candidate, but first of all (in v.5) we should mark it as >> deprecated. > > Sounds good. > v4 is not yet released. We may deprecate QLI in v4 already and remove in master. It's a feature not really used, it's not maintained, and in the worst cases, people could get it from v4 and use with v5. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
19.05.2021 12:53, Dimitry Sibiryakov пишет: It is what SET BIND is for. Not really. It's OK to replace DECFLOAT with DOUBLE, but what to do with simple arithmetics where 1/1 returns INT instead of DOUBLE? Do you want to replace all returned INTs? Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
19.05.2021 11:50, Dmitry Yemanov wrote: so we can "support" dialect 1 by silent ignore. Returned data types will be different, this may break existing applications. It is what SET BIND is for. It can be used in "on connect" triggers on per-application basis, right? -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
19.05.2021 12:34, Dimitry Sibiryakov wrote: AFAIR these discussions, people wanted new features in it (such as BIGINT) and the only named advantage was double precision arithmetic. This is covered by INT128/DECFLOAT arithmetic in v4 if I'm not mistaken Correct. so we can "support" dialect 1 by silent ignore. Returned data types will be different, this may break existing applications. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
19.05.2021 12:27, Alex Peshkoff via Firebird-devel wrote: UDF was been deprecated in FB 4. Could we remove them from master for v5? Doubt that. UDF is too actively used feature, lot of users will not be happy. Generally, it's OK to remove already deprecated features in the next major release. However, if we speak about a fast release, then maybe removing would be an overkill and it should happen only in v6 -- to give users more than one year to adjust their logic. Also QLI, I believe nobody uses it and there should be no good reason to maintain it. I know TCS uses it, so it should be changed. Good candidate, but first of all (in v.5) we should mark it as deprecated. Sounds good. I have the same question about dialect 1 A few years ago it was discussed but people continued (at least continued that time) to use it... Same as item 1 above. We can do it now, but perhaps better to wait a bit. and multi-file databases (which already were supposed to be removed in 4.0). OK for removal on my mind - not needed, not used for long ago, not compatible with nbackup. I remember (at least) Dalton Calford using them and voting strongly against the removal. So perhaps we should deprecate them now but drop only once we introduce tablespaces. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
19.05.2021 11:27, Alex Peshkoff via Firebird-devel wrote: I have the same question about dialect 1 A few years ago it was discussed but people continued (at least continued that time) to use it... AFAIR these discussions, people wanted new features in it (such as BIGINT) and the only named advantage was double precision arithmetic. This is covered by INT128/DECFLOAT arithmetic in v4 if I'm not mistaken so we can "support" dialect 1 by silent ignore. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
On 5/19/21 12:42 AM, Adriano dos Santos Fernandes wrote: Hi! UDF was been deprecated in FB 4. Could we remove them from master for v5? Doubt that. UDF is too actively used feature, lot of users will not be happy. Also QLI, I believe nobody uses it and there should be no good reason to maintain it. I know TCS uses it, so it should be changed. Good candidate, but first of all (in v.5) we should mark it as deprecated. I have the same question about dialect 1 A few years ago it was discussed but people continued (at least continued that time) to use it... and multi-file databases (which already were supposed to be removed in 4.0). OK for removal on my mind - not needed, not used for long ago, not compatible with nbackup. Let me also add suggest gsec and related services - was deprecated in fb3. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Deprecations
18.05.2021 23:42, Adriano dos Santos Fernandes wrote: UDF was been deprecated in FB 4. Could we remove them from master for v5? I have the same question about dialect 1 and multi-file databases (which already were supposed to be removed in 4.0). -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
