I don't see the compatibility point in returning column names as either fully qualified or not. The effort to support both automatically by that piece of software which is parsing a DB engine's return values is quite small: it only has to accept additional '.' chars inside a column name. That code is still generic enough to work with all DBs.On 02/19/2004 05:12 am, D. Richard Hipp wrote: > Question to all: If I modified SQLite to use the > same column naming rules as (say) PostgreSQL, how > much existing code would it break? Is this something > that should be done, even though it is a (slightly) > incompatible change?
Compatibility is really important. I'm dealing with that issue this very moment, we want our code to be completely compatible between SQLite and MySQL so the user can decide on the backend to use based on their specific needs.
Scott
Regarding compatibility: there are more and harder to circumvent topics here. Think AUTO_INCREMENT, for example: a nice feature (even, if I get it right, not near to standard SQL.) But in MySQL one has to specify AUTO_INCREMENT to a column, whereas the same SQL statement is not accepted in SQLite. Vice versa, a column definition which results in an AUTO_INCREMENT column in SQLite, results in a "common" INTEGER PRIMARY KEY NOT NULL column in MySQL.
/eno
BTW: currently using 2.8.6.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
