I agree very much with your suggestion. Although all those vendor specific "extensions" generally make the designers and coders lives easier, the wheels tend to come off in onerous ways when a heavily extended project migration is attempted.
Even when using a given vendor's product I have, based on past experiences, made every effort to avoid the "gray" areas (IBM manuals highlight extensions with gray background) of a particular vendor's product. In the long run it will serve a project well no matter the project's size or level of complexity. I have single user PC based projects that I have, over their life, migrated to more than one vendors database. (Do I know how to pick a loser?) And I have participated in projects where a migration from the likes of Oracle to SQL Server (no matter how ill advised) have been made. Therefore I strongly adhere to the SQL Standard whenever possible. This tends to cause less future work in the long run. Although that approach does not eliminate all conversion efforts, because most DB vendors can't even get the SQL Standard right :-( Fred > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Dennis Cote > Sent: Tuesday, February 12, 2008 9:41 AM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] Updatable views > > > John Stanton wrote: > > That ia a nice idea. To have a pragma which specied the > dialect. There > > could be "strict" or "ansi" and "mysql", "oracle", > "sqlserver" etc etc. > > It would give tighter control over hard to track annoying > minor syntax > > errors. > > > > I don't think we need anything that involved. Just a simple > standard SQL > mode and a the current SQLite mode with all its extensions in > place. The > second is needed as the default case for backward compatibility. The > first would let those who care move to standard SQL syntax. > > I would further suggest that SQLite could change its behavior > when the > next major version release happens, and make the standard mode the > default, since it is allowed to break backwards compatibility > at that time. > > Users migrating from other databases generally have to make some > modifications to their schema and SQL code since none of > these systems > are fully standard compliant, and most have some extensions > that are not > supported elsewhere. It would be relatively easy to make the changes > needed to use standard SQL quoting when migrating to SQLite > at that point. > > All these database products are continually moving to better > support for > the SQL standard. This would simply be another step along that road. > Once the database is converted to use standard quoting in SQLite it > would be portable to any of the other databases since they > all support > standard quoting. Similarly, databases created in SQLite > using standard > quoting would be more easily portable to any of these other databases > if the need arises. > > Dennis Cote > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
