--- In firebird-support@yahoogroups.com, bill_lam <bill_lam@...> wrote:

>
> Adam wrote:
> > My understanding is that the above syntax you provided is not part of
> > any SQL Standard. That alone does not mean it will never be supported,
> > sometimes a standard takes a long time to play catch up, but it is a
> > pretty good indication that one should not be expecting it to work in
> > any other database.
> >
> > If I am mistaken and this syntax does appear in the SQL standard, then
> > it could be put through as an enhancement request.
>
>
> I'm not alone in this issue, and I guess this may become an

recurrent question.

> If I read correctly, SQL Standard here refer to SQL92 (SQL2?) which is
> 2006-1992=14 years old, and Firebird itself have non-standard feature.

Are we ignoring SQL 99 and SQL 2003?

> Why call
> non-standard features of Firebird extensions; depreciate extensions

of other

> dbms as non-standard features?
>
> IMO market force rules not sQL92 standards. Just my 2 cents.

The problem is WHICH of the 'non-standard' features should be
implemented? Do they make sense? Are the benefits significant enough
to invest the time in designing, writing, testing and maintaining
feature X?

Many databases earn a lot of money for the companies that own them.
They need to employ vendor lock-in techniques to make sure that their
customers can't simply port to another database backend. In other
words, the customer uses feature X in their database not realising
that it is specific to their database engine, and have to make
substantial changes to port. When the customer realises this, it is
too late and they resign themselves to using whatever dbms they are
'committed to'.

Firebird itself does not benefit whether you or I use it or not,
unless someone donates to the Firebird Foundation, or assists in some
other way, or perhaps if your installation is significant it may
benefit in a marketing sense, but market forces are what commercial
software worries about, not free and open source software.

There is therefore no point in implementing something that does not
follow the standard UNLESS there actually is nothing in the standard
that can handle the proposed feature. By all means propose these
enhancements, if they are beneficial they may even get added, but it
is silly to propose another way of doing an update statement which
already has a well defined syntax and the proposed syntax is much
harder to follow. Each feature must be judged on its own merit, but
you have a much better chance of something happenning if you can show
a bunch of database vendors have agreed on it like a SQL standard.

Take for example a feature that has been around forever like a
generator. Its use predates the SQL standard of a sequence but is
conceptually the same thing. You can see that you can now CREATE
SEQUENCE etc.

The end result is that ideally you can change database engines without
too much hassle. (We are a while away from that reality).

Adam