You would be doing radix conversions all the time because you would be
mapping the full set of types available in your C (or whatever) program
in the limited set of types in Sqlite. Add to that the "manifest
typing" where the actual type can differ from the declared type.
A compiler has to
How about when you have a twos complement integer in your program and
Sqlite decides to return a character string?
Ken wrote:
From the standpoint of data insertions you wouldn't reall need to deal with
datatype correctness since sqlite is typeless.
John Stanton <[EMAIL PROTECTED]> wrote:
>From the standpoint of data insertions you wouldn't reall need to deal with
>datatype correctness since sqlite is typeless.
John Stanton <[EMAIL PROTECTED]> wrote: Why would it be a benefit? You would
have to be doing type conversions
all the time.
Ken wrote:
> I think the fact that
Why would it be a benefit? You would have to be doing type conversions
all the time.
Ken wrote:
I think the fact that sqlite is typeless actually is a benefit.
I see what you mean now about connecting to obtain the meta info. Maybe that could be embedded in the code as well for the
Or my contempt of code generators in general :-)
Fred
> -Original Message-
> From: Ken [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 11, 2007 12:46 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Sqlite Preprocessor
>
>
> I think the fact that sql
I think the fact that sqlite is typeless actually is a benefit.
I see what you mean now about connecting to obtain the meta info. Maybe that
could be embedded in the code as well for the pre-processor.
Thanks for your input.
Joe Wilson <[EMAIL PROTECTED]> wrote: ...and I was trying to
Yes, but probably simpler and more in the tradition of sqlite. Make it simple
and easy to use.
John Stanton <[EMAIL PROTECTED]> wrote: Are you proposing an implementation of
the existing Embedded SQL standard?
Ken wrote:
> Yes, a pre processor, but not a wrapper. A wrapper as I've seen from
It was one of the poorly thought through concepts which slipped into the
ash can of history without mourners.
To be reliable such a tool needs to be integrated into the development
system so that a change in schema forces a remake of all affected
applications. With discipline and the
Joe,
yes thats what I'm thinking.. The thing is the amount of code that can be
reduced via the preprocessor is enormous. Plus the fact that one could also
preprocess into the resulting C code all sorts of wonderful error handling in
a very succinct language construct.
I hapen to perfer
> Yes, a pre processor, but not a wrapper. A wrapper as I've seen from the
> sqlite.org site is
> simply a layer on top of the sqlite3 api. I've written my own wrapper. I'm
> really looking to
> see if instead of inserting an additional layer, the actual code could be
> compiled inline into
>
Are you proposing an implementation of the existing Embedded SQL standard?
Ken wrote:
Yes, a pre processor, but not a wrapper. A wrapper as I've seen from the sqlite.org site is simply a layer on top of the sqlite3 api. I've written my own wrapper. I'm really looking to see if instead of
Yes, a pre processor, but not a wrapper. A wrapper as I've seen from the
sqlite.org site is simply a layer on top of the sqlite3 api. I've written my
own wrapper. I'm really looking to see if instead of inserting an additional
layer, the actual code could be compiled inline into the sourcing
My understanding is that he is advocating a compiler which would take
his definition of an Sqlite operation and generate correct Sqlite3 API
calls.
An existing wrapper could well satisfy his requirement.
Joe Wilson wrote:
I not sure what you mean by preprocessor, but if you mean a
"stored
I not sure what you mean by preprocessor, but if you mean a
"stored procedure language", sqlite does not support an official one
within the database itself.
There are, however, dozens of bindings to computer languages
in addition to the Tcl wrapper that ships with sqlite:
Does a preprocessor exist for sqlite and if so where ?
If not that might be a really nice project to be able to support
syntax as follows:
SQLITE_EXEC at :loginhndllogin "dbname.db";
SQLITE_EXEC at :loginhndl declar cursor c1;
SQLITE_EXEC at :loginhndl prepare cursor c1 using
Does a preprocessor exist for sqlite and if so where ?
If not that might be a really nice project to be able to support syntax as
follows:
SQLITE_EXEC at :loginhndllogin "dbname.db";
SQLITE_EXEC at :loginhndl declar cursor c1;
SQLITE_EXEC at :loginhndl prepare cursor c1 using sqlStr;
16 matches
Mail list logo
