Firebird Future Development [LWN.net]

Firebird database project coordinator Dmitry Yemanov presents a project roadmap for upcoming Firebird development. ""What then?", - you ask. I'd describe Firebird 2.0 as "the version which removes the annoying limits". Sounds not so modest, I know. Let me explain better. No doubt that Firebird has a nice multi-generational architecture and a rich SQL language, an embedded usage and a good performance. But I'm sure almost everyone stepped on some internal limitations that worried or even shocked you."

to post comments

Firebird Future Development

Posted Nov 29, 2005 22:36 UTC (Tue) by leandro (guest, #1460) [Link] (3 responses)

They keep talking about SQL 99, but it was canceled out by ISO SQL:2003. Each revision of ISO SQL cancels the previous ones, so that any claims of ISO SQL:(19(89|9[29]) are irrelevant.

Pedantic

Posted Nov 29, 2005 22:59 UTC (Tue) by AnswerGuy (guest, #1256) [Link]

Every DBMS lists its target compliance in terms of the most recent SQL standard to which they aspire. Also each new SQL standards release is mostly built on the previous one.

So there is nothing irrelevant in hearing that they've added a number of SQL-99 compliant features. It would be interesting if you saw and listed any of them which are specifically superceded by something in the 2003 version, or even if you linked to some useful summary of the salient differences such as:

ACM: SQL-2003 Has been Published

JimD

Firebird Future Development

Posted Nov 30, 2005 17:57 UTC (Wed) by fsgg (guest, #34223) [Link] (1 responses)

> They keep talking about SQL 99, but it was canceled out by ISO SQL:2003.
> Each revision of ISO SQL cancels the previous ones, so that any claims of
> ISO SQL:(19(89|9[29]) are irrelevant.

Hm, and wich rdbms you know of does comply fully to any of the aforementioned standards? :-)

Frank

Firebird Future Development

Posted Aug 4, 2006 21:40 UTC (Fri) by leandro (guest, #1460) [Link]

wich rdbms you know of does comply fully to any of the aforementioned standards?

None, even if IBM DB2 and PostgreSQL come close, as Mimer do. But they are not RDBMSs; nowadays there aren't many, Alphora Dataphor and Rel come to mind, besides the G-Exec2 project.

But my point was that people show know what they talk about.

Firebird Future Development

Posted Nov 30, 2005 22:26 UTC (Wed) by helebor (guest, #34227) [Link]

Score for leandro: 0 (ignoramus).

New versions of the SQL standard don't wipe out previous versions. The purpose of the standards is to define how an implementation should be surfaced in the language of that RDBMS **IF** it is implemented in that language, certainly NOT to arbitrarily change existing standards every few years.

Making the existing implementation of a feature "SQL-nnnn-compliant" means taking a feature that was implemented in that RDBMS before a standard existed for that feature and re-implementing it once the standard is known. So a feature isn't going to be reimplemented as e.g. "SQL-2003-compliant" if the standard for that feature was first published in SQL-99 and didn't change in SQL-2003.

When introducing a feature into the language sets of a RDBMS, it's recommended practice always to make it compliant with the standard if a standard exists for it. The publication of new standards takes years and always lags far behind the NEED for specific standards. Hence, reimplementing (commonly advanced) features to comply with what the standards committee eventually publishes is part of a responsible, professional software development process.

Furthermore, anyone who actually understands database development will understand clearly that reimplementations of existing language features are not done lightly. The new implementation surfaces new syntax which would break existing application and stored procedure code if it were pushed in without keeping the old implementation available. The old implementation is usually declared "deprecated", which warns developers that it will disappear some time in the future. This, too, is essential to a responsible development process.

Therefore, if a new version of the standards - SQL-2003, for example - defines new or extended syntax for a feature that existed in a previous standard, it is essential that the new syntax remains consistent with the existing syntax. It's not the purpose of the standards committee to break things. Many deprecated features exist in the standards, as well.