On Wed, Oct 31, 2012 at 8:37 PM, Ann Harrison a...@qbeast.net 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.
I
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 division.
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
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 applications
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
On Thu, Nov 1, 2012 at 3:03 PM, Carlos H. Cantu lis...@warmboot.com.br 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
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
On 1 November 2012 09:23, marius adrian popa map...@gmail.com 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
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 Thu, Nov 1, 2012 at 9:32 AM, Dimitry Sibiryakov s...@ibphoenix.com 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
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
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
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
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
действительно блокирует доставку АСТов на время скана
14 matches
Mail list logo
