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
> 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, 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
>
> 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
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 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 legac
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
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 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
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
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: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
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
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
| [{
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 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,
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
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 fas
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
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
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 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 de
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: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
>
> "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
>
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
--
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 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 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
> 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
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 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
>> 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 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 ju
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
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
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 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
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
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 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
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 exis
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
> N1 DIVIDE
>
= ===
>
1.230 0.6150
>
10.230 5.115
>
3.567 1.7835000
>
>
>
-- Test with current dialect 1
>
>
Statement failed,
> > 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
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
> 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: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
54 matches
Mail list logo
