02.11.2012 8:33, Dmitry Yemanov wrote:
[skip]
Sorry for posting in Russian, it was intended to go privately :-)
Dmitry
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update so
01.11.2012 23:28, Nikolay Samofatov пишет:
>
> I privately discussed this issue with Dmitry and would like to confirm here
> that backing out the
> patch indeed fixes the problem.
У вас проблеима вызвана сочетанием двух вещей. Патч для 3034
действительно блокирует доставку АСТов на время скана к
> Hello, All!
>
> The fix effectively disables JRD_reschedule calls. For example in
> btr.cpp:scan() JRD_reschedule will
> never yield control to another thread because it is always called with at
> least one latch.
>
> Since AST processing in Firebird 2.5 and later requires yield of control t
Hello, All!
The fix effectively disables JRD_reschedule calls. For example in
btr.cpp:scan() JRD_reschedule will
never yield control to another thread because it is always called with at least
one latch.
Since AST processing in Firebird 2.5 and later requires yield of control this
means that
I have seen that old_prefixes in is not used anymore
trunk/builds/old_prefixes/
http://firebird.svn.sourceforge.net/viewvc/firebird/firebird/trunk/builds/old_prefixes/
This is the old makefile area, left over from the InterBase unix build
procedures. They have been replaced in src/make.new with
Error in selecting rows with compound index
---
Key: CORE-3971
URL: http://tracker.firebirdsql.org/browse/CORE-3971
Project: Firebird Core
Issue Type: Bug
Components: Engine
Affects Versi
Hi *,
The Sparky from Firebird Conference in Italy in 2008 is ready for
re-auction. More info in description: http://r.ebay.com/l7uMc5 .
--
Jiri {x2} Cincura (x2develop.com founder)
http://blog.cincura.net/ | http://www.ID3renamer.com
-
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.
>>
25 matches
Mail list logo
