On Thu, Nov 1, 2012 at 3:59 AM, Mark Rotteveel wrote:
>
> I am not familiar with exact nature of the precision issues with NUMERIC
> and DECIMAL calculations, but didn't that also follow the SQL spec (and if
> not: shouldn't we correct it?
Borland interpreted the SQL Standard to say that the i
On Thu, Nov 1, 2012 at 9:32 AM, Dimitry Sibiryakov wrote:
>
>
>Way to nowhere. No matter how long new datatype is, 1/3 won't be
> precise.
>
1/3 is precise in base 6, though of course 1/5 isn't. And frankly, double
precision
doesn't help much either since it can't represent 1/3 (base 10) pr
On Thu, Nov 1, 2012 at 5:00 AM, Dmitry Yemanov wrote:
> 01.11.2012 11:43, marius adrian popa wrote:
>
> > And the quad is gone
>
> Not really. What has gone is the quad specific arithmetics.
> The data type itself remains and I doubt it can be wiped out completely,
> as AFAIK sometimes it's used
On Thu, 01 Nov 2012 14:32:35 +0100, Dimitry Sibiryakov
wrote:
> 01.11.2012 14:26, Dmitry Yemanov wrote:
>> The obvious one (though not necessarily meaning the only one) is to
have
>> even longer numerics and use them in cases when an int64 based
>> intermediate result is likely to overflow.
>
>
01.11.2012 17:32, Dimitry Sibiryakov wrote:
> Way to nowhere. No matter how long new datatype is, 1/3 won't be precise.
1/3 = 0 in dialect 3, IIRC. No precision problems at all.
Dmitry
--
Everyone hates slow websites.
On 1 November 2012 09:23, marius adrian popa wrote:
>
> Maybe is time for Dialect 4 with all the Dialect 3+1 fixes
>
>
Perhaps with longer SQL Object identifiers ie CHAR(80) UTF8 and schema
support ie select * from SCHEMANAME.TABLENAME so that it is easier to
migrate from other platforms to Fire
01.11.2012 14:26, Dmitry Yemanov wrote:
> The obvious one (though not necessarily meaning the only one) is to have
> even longer numerics and use them in cases when an int64 based
> intermediate result is likely to overflow.
Way to nowhere. No matter how long new datatype is, 1/3 won't be preci
01.11.2012 17:02, Kjell Rilbe wrote:
> If it's not too complicated to describe (it's just out of curiosity...),
> then please what is the "proper solution"?
The obvious one (though not necessarily meaning the only one) is to have
even longer numerics and use them in cases when an int64 based
in
On Thu, Nov 1, 2012 at 3:03 PM, Carlos H. Cantu wrote:
> DY> The proper solution is far not trivial to implement.
>
> Ok, but I understand that even not being trivial, it can be
> implemented :)
>
> DY> An easier one will break existing applications as they will start
> DY> calculating different n
DY> The proper solution is far not trivial to implement.
Ok, but I understand that even not being trivial, it can be
implemented :)
DY> An easier one will break existing applications as they will start
DY> calculating different numbers for the same queries.
I think his is a relative point of vie
Den 2012-11-01 13:26 skrev Dmitry Yemanov såhär:
> 01.11.2012 15:16, Carlos H. Cantu wrote:
>
>> If the problem is due to the way Borland implemented numeric/decimal
>> math in dialect 3, why not just fix it? (no idea about how difficult it
>> would be)
> The proper solution is far not trivial to i
01.11.2012 15:16, Carlos H. Cantu wrote:
> If the problem is due to the way Borland implemented numeric/decimal
> math in dialect 3, why not just fix it? (no idea about how difficult it
> would be)
The proper solution is far not trivial to implement. An easier one will
break existing application
LS> If it was not the case that other project teams members (Dmitry Y
LS> and Ann H) have acknowledged that there are significant issues
LS> with migration due to Borland's Dialect 3 implementation/rules,
LS> then I would agree that sponsor $$$ could be a factor.
If the problem is due to the way B
On Thu, Nov 1, 2012 at 11:00 AM, Dmitry Yemanov wrote:
> 01.11.2012 11:43, marius adrian popa wrote:
>
>> And the quad is gone
>
> Not really. What has gone is the quad specific arithmetics.
> The data type itself remains and I doubt it can be wiped out completely,
> as AFAIK sometimes it's used f
01.11.2012 11:43, marius adrian popa wrote:
> And the quad is gone
Not really. What has gone is the quad specific arithmetics.
The data type itself remains and I doubt it can be wiped out completely,
as AFAIK sometimes it's used for blob IDs.
BTW, another data type that seems asking for a clean
01.11.2012 11:59, Mark Rotteveel wrote:
> As far as I know the CAST behavior in dialect 3 conforms to the SQL
> standards, while those in dialect 1 don't. I don't think that
> non-conformance is a good reason to stick to Dialect 1.
It's not about CAST per se, it's about multiplication and divisio
On Wed, 31 Oct 2012 20:23:41 -0400, "Leyne, Sean"
wrote:
> The most significant issue is that way that the precision that math
> operations have in Dialect 3 vs. Dialect 1 and the need to add CAST
> operands to existing syntax (where none is required in Dialect 1).
As far as I know the CAST behav
On Wed, Oct 31, 2012 at 8:37 PM, Ann Harrison wrote:
> Dmitry,
>
>>
>> Can we conclude that no client app existing these days should be able to
>> deal with blr_quad / dtype_quad?
>
>
> Unless somebody is running a 20 year old app on a Vax ...
>>
>>
>> This sounds as a good cleanup possibility.
>>
On 31-10-2012 22:54, Leyne, Sean wrote:
>
> If it was not the case that other project teams members (Dmitry Y and Ann H)
> have acknowledged that there are significant issues with migration due to
> Borland's Dialect 3 implementation/rules, then I would agree that sponsor $$$
> could be a fact
> On 31-10-2012 22:23, Leyne, Sean wrote:
> >
> >
> >>> Over all 12 years of FB development it became clear that *remaining*
> >>> dialect 1 users simply can't switch at all (old legacy app, they
> >>> certainly switch with new app. versions), so giving them another 2
> >>> years inserting deprec
On 31-10-2012 22:23, Leyne, Sean wrote:
>
>
>>> Over all 12 years of FB development it became clear that *remaining*
>>> dialect 1 users simply can't switch at all (old legacy app, they
>>> certainly switch with new app. versions), so giving them another 2
>>> years inserting deprecation version
> > Over all 12 years of FB development it became clear that *remaining*
> > dialect 1 users simply can't switch at all (old legacy app, they
> > certainly switch with new app. versions), so giving them another 2
> > years inserting deprecation version before removal will not help them
> > in any
Dmitry,
> Can we conclude that no client app existing these days should be able to
> deal with blr_quad / dtype_quad?
>
Unless somebody is running a 20 year old app on a Vax ...
>
> This sounds as a good cleanup possibility.
>
> I guess. Since it wasn't used for the new 64 bit integers...
Ann
Ann,
> InterBase was developed on MicroVaxen which had a 64-bit integer
> datatype. So from
> V1, there was support for what was called "QUAD". Contemporary Intel
> and Motorola
> processors did not support the type, so it was dropped for those versions.
Can we conclude that no client app exis
On Wed, Oct 31, 2012 at 6:51 AM, Mark Rotteveel wrote:
>
> Also didn't Firebird internally already have 64 bit fields (eg
> DOUBLE, ISC_QUAD), or are all those also artefacts of dialect 3?
>
InterBase was developed on MicroVaxen which had a 64-bit integer datatype.
So from
V1, there was support
31.10.2012 17:42, marius adrian popa wrote:
> I see that 3.0 is in feature freeze mode
No, it's not.
Dmitry
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Li
On Wed, Oct 31, 2012 at 2:18 PM, Adriano dos Santos Fernandes
wrote:
> On 31/10/2012 10:12, Mark Rotteveel wrote:
>> Databases and applications still using dialect 1 should simply take the
>> effort now to switch, or remain left behind on Firebird 2.5 max. It is the
>> consequence of a decision to
On 31/10/2012 10:12, Mark Rotteveel wrote:
> Databases and applications still using dialect 1 should simply take the
> effort now to switch, or remain left behind on Firebird 2.5 max. It is the
> consequence of a decision to continue to use a legacy option. Continuing
> support for dialect 1 in Fir
Pavel Cisar wrote:
>> Pavel Cisar wrote:
>>> >>b) If we will announce the removal of dialect 1 support now, users of
>>> >>dialect 1 planning to switch to FB 3.0 will have at least 1.5 years to
>>> >>adapt their applications (for early adoption) and about 5-7 years as
>>> >>final deadline (when sup
On Wed, 31 Oct 2012 15:54:11 +0400, Alex Peshkoff
wrote:
> On 10/31/12 15:45, Pavel Cisar wrote:
>>
>> Dne 31.10.2012 12:26, Alex Peshkoff napsal(a):
>>> On 10/31/12 15:03, Pavel Cisar wrote:
>>> Let me answer. As a minimum - shared pages cache and i.e. better SMP
>>> support.
>> But only if you n
On 10/31/12 15:45, Pavel Cisar wrote:
>
> Dne 31.10.2012 12:26, Alex Peshkoff napsal(a):
>> On 10/31/12 15:03, Pavel Cisar wrote:
>> Let me answer. As a minimum - shared pages cache and i.e. better SMP
>> support.
> But only if you need both of them at the same time, individually they're
> provided
Dne 31.10.2012 12:26, Alex Peshkoff napsal(a):
> On 10/31/12 15:03, Pavel Cisar wrote:
>>
>
> Let me answer. As a minimum - shared pages cache and i.e. better SMP
> support.
But only if you need both of them at the same time, individually they're
provided by pre-3.0 versions. Anyway, this is ju
> 31.10.2012 15:32, Thomas Steinmaurer wrote:
>
>> Management = Firebird Admin List?
>
> Nope, I meant just another part of my responsibilities ;-)
Ah, ok. I guess you have a bunch of hats for different roles in your
garderobe then. ;-)
Regards,
Thomas
-
>> Over all 12 years of FB development it became clear that *remaining*
>> dialect 1 users simply can't switch at all (old legacy app, they
>> certainly switch with new app. versions), so giving them another 2 years
>> inserting deprecation version before removal will not help them in any
>> signif
31.10.2012 14:36, Pavel Cisar wrote:
>
> a) It's mostly about pre-IB 6.0 applications that were not adapted to
> dialect 3 since then. How many such apps do you think it's still out
> there? Up to 0.01% ?
>
> b) All new applications since IB 6.0 / FB 1.0 are dialect 3
> applications, with very very
31.10.2012 15:32, Thomas Steinmaurer wrote:
> Management = Firebird Admin List?
Nope, I meant just another part of my responsibilities ;-)
Dmitry
--
Everyone hates slow websites. So do we.
Make your web apps faster wi
> 31.10.2012 12:50, Thomas Steinmaurer wrote:
>>
>>> That said, I'm against the idea in general ;-)
>
> Sorry, I had intended to write:
>
> "That said, I'm NOT against the idea in general"
Ah, even better. ;-)
> as it should obviously be wiped out sooner rather than later. But this
> is exactly t
On 31/10/2012 08:36, Pavel Cisar wrote:
>
> Over all 12 years of FB development it became clear that *remaining*
> dialect 1 users simply can't switch at all (old legacy app, they
> certainly switch with new app. versions), so giving them another 2 years
> inserting deprecation version before re
On 10/31/12 15:03, Pavel Cisar wrote:
>
> Dne 31.10.2012 11:46, Lester Caine napsal(a):
>> Pavel Cisar wrote:
>>> b) If we will announce the removal of dialect 1 support now, users of
>>> dialect 1 planning to switch to FB 3.0 will have at least 1.5 years to
>>> adapt their applications (for early
On Wed, 31 Oct 2012 15:06:30 +0400, Dmitry Yemanov
wrote:
> 31.10.2012 14:51, Mark Rotteveel wrote:
>
>> But to the original problem: Why not just declare it as a
NUMERIC(27,0),
>> as I believe that is the equivalent to BIGINT, or doesn't that apply to
>> dialect 1?
>
> NUMERIC(18) is the maximu
On 31/10/2012 08:47, Mark Rotteveel wrote:
> IMHO dialect 1 could already be considered deprecated since Interbase
> 6.0/Firebird 1.0. Providing a new dialect (3) and a dialect to migrate (2)
> is - to me - a clear sign of deprecation.
>
>
I agree.
Adriano
--
>
> "That said, I'm NOT against the idea in general"
>
> as it should obviously be wiped out sooner rather than later. But this is
> exactly the case when my personal humble opinion conflicts with the
> management one. But let's hear other opinions as well, I'm not a dictator ;-)
>
>
> Dmitry
>
Dne 31.10.2012 11:40, Dimitry Sibiryakov napsal(a):
> 31.10.2012 11:36, Pavel Cisar wrote:
>> So negative impact would be to very small fraction of FB users, while
>> positive impact would affect the rest.
>
> Could you tell more about this "positive impact"?..
For example:
1. Cleaner code
31.10.2012 14:51, Mark Rotteveel wrote:
> But to the original problem: Why not just declare it as a NUMERIC(27,0),
> as I believe that is the equivalent to BIGINT, or doesn't that apply to
> dialect 1?
NUMERIC(18) is the maximum we can offer. And yes, it's different between
dialects 1 and 3. It'
Dne 31.10.2012 11:46, Lester Caine napsal(a):
> Pavel Cisar wrote:
>> b) If we will announce the removal of dialect 1 support now, users of
>> dialect 1 planning to switch to FB 3.0 will have at least 1.5 years to
>> adapt their applications (for early adoption) and about 5-7 years as
>> final de
On 10/31/12 14:39, Dmitry Yemanov wrote:
> 31.10.2012 14:29, Adriano dos Santos Fernandes wrote:
>> I'd prefer to hack on allowing BIGINT on dialect 1
> So far it looks like a lesser evil.
>
what about char(8) octets?
Last try :-)
-
On Wed, 31 Oct 2012 14:39:13 +0400, Dmitry Yemanov
wrote:
> 31.10.2012 14:17, Alex Peshkoff wrote:
>
>> what about having 2 32-bit fields in
>> ODS12? In ODS13 we will remove that hack
>
> I don't think we can remove system fields at all, at least without
> breaking an unknown number of applica
On Wed, 31 Oct 2012 13:02:50 +0400, Dmitry Yemanov
wrote:
> 31.10.2012 12:50, Thomas Steinmaurer wrote:
>>
>>> That said, I'm against the idea in general ;-)
>
> Sorry, I had intended to write:
>
> "That said, I'm NOT against the idea in general"
>
> as it should obviously be wiped out sooner r
Pavel Cisar wrote:
> b) If we will announce the removal of dialect 1 support now, users of
> dialect 1 planning to switch to FB 3.0 will have at least 1.5 years to
> adapt their applications (for early adoption) and about 5-7 years as
> final deadline (when support of last FB version having dialect
31.10.2012 11:36, Pavel Cisar wrote:
> So negative impact would be to very small fraction of FB users, while
> positive impact would affect the rest.
Could you tell more about this "positive impact"?..
--
WBR, SD.
---
31.10.2012 14:29, Adriano dos Santos Fernandes wrote:
>
> I'd prefer to hack on allowing BIGINT on dialect 1
So far it looks like a lesser evil.
Dmitry
--
Everyone hates slow websites. So do we.
Make your web apps fas
31.10.2012 14:17, Alex Peshkoff wrote:
> what about having 2 32-bit fields in
> ODS12? In ODS13 we will remove that hack
I don't think we can remove system fields at all, at least without
breaking an unknown number of applications. And requiring users to
decode the trigger type based on either
Hi,
Well, if removing dialect 1 in FB 3.0 is NOT out of question, I'm
strongly for its removal (not just deprecation) in 3.0. While some may
object that it's:
a) violation of our deprecation policy.
b) not advance enough notification to give users time to adapt.
I would like point out that:
a
On 31/10/2012 08:17, Alex Peshkoff wrote:
> On 10/31/12 13:39, Adriano dos Santos Fernandes wrote:
>> On 31/10/2012 07:21, Alex Peshkoff wrote:
>>> Returning to initial problem.
>>> Do we suppose to
>>> create /*for example*/ trigger on create table or alter exception or
>>> drop role?
>>> If yes,
On 10/31/12 13:39, Adriano dos Santos Fernandes wrote:
> On 31/10/2012 07:21, Alex Peshkoff wrote:
>> Returning to initial problem.
>> Do we suppose to
>> create /*for example*/ trigger on create table or alter exception or
>> drop role?
>> If yes, bitmask encoding in int64 makes sense.
> This is w
On 31/10/2012 07:21, Alex Peshkoff wrote:
>
> Returning to initial problem.
> Do we suppose to
> create /*for example*/ trigger on create table or alter exception or
> drop role?
> If yes, bitmask encoding in int64 makes sense.
This is what it does:
::=
ANY DDL STATEMENT
| [{
31.10.2012 13:21, Dmitry Yemanov wrote:
> It was an old (FB1.5 time) decision to avoid some new features in
> Dialect 3
Dialect 1, of course. I seem to be keyboard unfriendly today :-D
Dmitry
--
Everyone hates slow we
31.10.2012 13:15, Dimitry Sibiryakov wrote:
> I wonder why you don't allow to use BIGINT in dialect 1...
It was an old (FB1.5 time) decision to avoid some new features in
Dialect 3, especially those that old clients may be not prepared to deal
with. However, I must admit that that rule was not
On 10/31/12 13:02, Dmitry Yemanov wrote:
> 31.10.2012 12:50, Thomas Steinmaurer wrote:
>>> That said, I'm against the idea in general ;-)
> Sorry, I had intended to write:
>
> "That said, I'm NOT against the idea in general"
>
> as it should obviously be wiped out sooner rather than later. But this
31.10.2012 13:12, Nando Dessena wrote:
>
> Deprecating dialects in Fb3 will not hurt anyone but at the same time
> deliver a message.
> Then you can postpone the decision to wipe them in the next release or
> later.
No objections here, it just doesn't resolve the original problem Adriano
is facin
31.10.2012 10:02, Dmitry Yemanov wrote:
> as it should obviously be wiped out sooner rather than later. But this
> is exactly the case when my personal humble opinion conflicts with the
> management one. But let's hear other opinions as well, I'm not a
> dictator;-)
I wonder why you don't allow
Dmitry,
> 31.10.2012 12:50, Thomas Steinmaurer wrote:
>>
>>> That said, I'm against the idea in general ;-)
>
> Sorry, I had intended to write:
>
> "That said, I'm NOT against the idea in general"
>
> as it should obviously be wiped out sooner rather than later. But
> this is exactly the case when
31.10.2012 12:50, Thomas Steinmaurer wrote:
>
>> That said, I'm against the idea in general ;-)
Sorry, I had intended to write:
"That said, I'm NOT against the idea in general"
as it should obviously be wiped out sooner rather than later. But this
is exactly the case when my personal humble opi
> 31.10.2012 12:29, Thomas Steinmaurer wrote:
>
>>> IMHO: Dropping dialect 1 and 2 should be done with Firebird 3. People
>>> still depending on dialect 1 will then be stuck on Firebird 2.5 until they
>>> migrate to dialect 3. I think that is a better option than keep dragging
>>> support for legac
On 10/31/12 12:40, Dmitry Yemanov wrote:
> 31.10.2012 12:29, Thomas Steinmaurer wrote:
>
>>> IMHO: Dropping dialect 1 and 2 should be done with Firebird 3. People
>>> still depending on dialect 1 will then be stuck on Firebird 2.5 until they
>>> migrate to dialect 3. I think that is a better option
31.10.2012 12:29, Thomas Steinmaurer wrote:
>> IMHO: Dropping dialect 1 and 2 should be done with Firebird 3. People
>> still depending on dialect 1 will then be stuck on Firebird 2.5 until they
>> migrate to dialect 3. I think that is a better option than keep dragging
>> support for legacy compa
> On Wed, 31 Oct 2012 08:41:39 +0100, "Paul Beach"
> wrote:
>>> I have no idea what to do (well, actually I have a very easy and good
>>> one, you know, it's to wipe dialect 1/2). I'd hate to split a single
>>> field in two to support something which should be removed +10 years
> ago.
>>
>> <> fir
On Wed, 31 Oct 2012 08:41:39 +0100, "Paul Beach"
wrote:
>> I have no idea what to do (well, actually I have a very easy and good
>> one, you know, it's to wipe dialect 1/2). I'd hate to split a single
>> field in two to support something which should be removed +10 years
ago.
>
> < firebird 1.0
>
> I have no idea what to do (well, actually I have a very easy and good
> one, you know, it's to wipe dialect 1/2). I'd hate to split a single
> field in two to support something which should be removed +10 years ago.
<>
They haven't
Paul
On Wed, Oct 31, 2012 at 2:51 AM, Adriano dos Santos Fernandes
wrote:
> Hi!
>
> RDB$TRIGGERS.RDB$TRIGGER_TYPE was extended to BIGINT in v3, to support
> DDL triggers.
>
> It was difficult to found what was going wrong with CORE-3964, but then
> I found it.
>
> First, INI_init checks DBB_DB_SQL_dial
Hi!
RDB$TRIGGERS.RDB$TRIGGER_TYPE was extended to BIGINT in v3, to support
DDL triggers.
It was difficult to found what was going wrong with CORE-3964, but then
I found it.
First, INI_init checks DBB_DB_SQL_dialect_3 which works on database
creation, but on opening, it's set only in PAG_header (
71 matches
Mail list logo
