John Elrick wrote:
Michael Schlenker wrote:
A. Pagaltzis schrieb:
* Samuel R. Neff <[EMAIL PROTECTED]> [2007-05-30 14:55]:
SQLite's typelessness is an asset if you work only with SQLite
but in any application that uses multiple database engines of
which SQLite is only one supported engine, the non-standard
typelessness is something that has to be worked around.
Can you give an example of such a case? I work with several
different DBMSs, myself, and I have yet to run into trouble with
SQLite’s approach. Can you give a reallife example?
Start by already having a wrapper that allows type introspection (
e.g. DESCRIBE on oracle and reading the result set to find out what
types are returned)
such a feature is basically non-portable to SQLite.
Although it would require some work, a thought that comes to mind would
be to build a wrapper for create table which would permit you define any
types you wish and then store the information in a separate table which
in some way mirrors sqlite_master.
Introspection would occur via this mechanism and would even move all
introspection for any given system behind a common interface.
Just a thought.
John Elrick
CREATE TABLE already stores the type as its declared type. The user has
that available to enforce type restrictions or to direct type conversions.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
