Actually I was talking about an application language which lets users
incorporate their own SQL and which binds to the SQL at run time rather
than being like embedded SQL.
It doesn't need to parse SQL, it just uses the existing SQL API which
provides all the necessary capability.
The application language compiler does not need to parse the SQL.
When I was writing the compiler I thought of looking at the SQL but soon
realized that it was not necessary, the Sqlite API had enough
functionality to make that unecessary.
As I said before, the users of my application language declare Sqlite
columns to be anything their application would like to see. The binding
logic retrieves that declared type (e.g. DECIMAL(5,2)) and gets the
actual type (which may be TEXT) and performs the appropriate move, in
that case a TEXT string of digits into a fixed point, display format
number.
Sqlite's "manifest typing" has been carefully thought through and is
almost all things for all people.
Andy Ross wrote:
John Stanton wrote:
> The method I wrote about earlier is part of a language binding.
> I can show you the code if you are interested.
I think we must be talking about different things, then. A language
binding that allows the user to write their own SQL cannot
automatically insert cast() calls into the queries without parsing the
SQL and making a runtime determination about the context in which each
bound parameter will be evaluated. And that's the halting problem. :)
Maybe you're talking about something like rails, which abstracts away
the SQL from the user API and generates its own queries? Then sure.
But that's not the level of abstraction I'm working with.
But regardless: sure, I'd be curious to see how you are dealing with
the same issue. What I've done for now is just change the default
from bind_blob() to bind_text(), and add some language to the docs
warning users that they need to add a cast-to-text when writing
expressions involving blob columns. Since comparing blob values is
obviously rare, this seems to me like an acceptable compromise.
Andy
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
