On Wed, Oct 31, 2012 at 2:51 AM, Adriano dos Santos Fernandes
adrian...@gmail.com 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
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.
Dialect 1/2 logic was for supporting migration of interbase 5 to firebird 1.0
I
On Wed, 31 Oct 2012 08:41:39 +0100, Paul Beach pbe...@ibphoenix.com
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.
On Wed, 31 Oct 2012 08:41:39 +0100, Paul Beach pbe...@ibphoenix.com
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.
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
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 opinion
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 my personal
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 facing.
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
is
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 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:
ddl event ::=
ANY DDL STATEMENT
|
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 what it
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, bitmask encoding
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:
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
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
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.
--
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 1
On Wed, 31 Oct 2012 13:02:50 +0400, Dmitry Yemanov firebi...@yandex.ru
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
On Wed, 31 Oct 2012 14:39:13 +0400, Dmitry Yemanov firebi...@yandex.ru
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
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 :-)
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 deadline
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's
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 - less
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
I think
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
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 few
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
significant
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
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 just
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 by
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 support of last FB
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
On Wed, Oct 31, 2012 at 2:18 PM, Adriano dos Santos Fernandes
adrian...@gmail.com 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
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
On Wed, Oct 31, 2012 at 6:51 AM, Mark Rotteveel m...@lawinegevaar.nlwrote:
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,
As an immediate workaround for subj., I propose to let BIGINT (and
DATEand TIME) to be passed for dialect 1 clients.
Thechanges just transform something that is currently an error into
something that may be unexpected (SQL_INT64) but will work for good clients.
Arithmetics will not be changed:
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 existing
N1 DIVIDE
= ===
1.230 0.6150
10.230 5.115
3.567 1.7835000
-- Test with current dialect 1
Statement failed, SQLSTATE
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 before
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 before
41 matches
Mail list logo
