Jim,

> Dmitry Yemanov wrote:
>
> >My opinion is that this behaviour is incorrect and not standard
> compliant.
> >Even its existence for 10 years is not a good excuse.
>
> But it is a good excuse.

It's not a great one.

If there wasn't a standard that gave some guidance as to the syntax then
you'd be a 100% correct.

But since there is a standard, it should be adhered to. Which means
that applications must change/be maintained to keep with the times.

> If you want to work on a database without
> legacy or mistakes, start your own. But then you won't have any

users.

> If want to work on a database system that has users, you have to

respect

> their investment, even their investment in ugly, inefficient
> workarounds.

In that case, developers don't need to use the Firebird 2.0 engine!

Further, given that this area of the engine is used exceptionally a
change would not impact many people.

No product can keep 100% backward compatibility forever!

> I agree that your idea is better than Borlands (after all,
> it was my original idea as well). OK, Borland screwed a lot of users
> when they went to version 4 that was substantially incompatible with
> version 3. And the vast majority of pre-Borland Unix customers left

for

> other products. Why? Not because version 4 was better or worse than
> version 3, but because it contained a large number of arbitrary
> incompatibilites.

Interestingly, Borland repeated this incompatibility when they
introduced INT64 support and 'broke' the compatibility of the NUMERIC
datatype -- precision in math operations.

Perhaps, the middle-ground between the two points of view, is to tie the
DDL compatibility with the Dialect. It has been done by Borland for
NUMERIC, and by Firebird for the SELECT ambiguity logic.

Proposal: Make Dialect 3 support the new/standard syntax and leave
Dialect 1 to support the old definition unchanged.


Sean