On Mon, 23 Feb 2004, [EMAIL PROTECTED] wrote: > Nevertheless, DRH has said he's working on this. I'm sure there's nothing > your or I could say that will improve his understanding of the problem :) > If there was, I'm also sure he'd ask.
Maybe so, but someone did start a discussion on this subject, and I thought I might be able to add value to it. I certainly wasn't intending to say that my ideas were unique. > This is easy to say, and easy to do in the back-end. I belive this is > more-or-less the direction DRH is heading in, although finding all those > pesky strcmp etc can be tricky... I was mainly talking about the back-end, which is the root of any significant issues. The parser et al is basically a wrapper for the back-end. > but what about the parser? How do you > parse the string: "INSERT INTO Foo VALUES (\"\0\"\");"? A human can see I > meant to insert the null character, then a quote. How does the parser of > this C string know not to stop at the first '\0', and how does it know > that the first '"' was meant to be part of the string? Do you force me to > put in a number in this syntax, too? "INSERT INTO Foo > Values(binary(2,\0\"));" could work, I suppose. Then you could say "SELECT > length(Bar),Bar FROM Foo;" to get the length and data so it can be copied > back out again... although it might be more convenient to include this > automatically in the callback function. Regarding this, I would say first of all that bind columns are a reasonable default way to pass any non-trivial literal values, and if done well can make things a lot faster and simpler. Even non-binary data has to be escaped to be put in SQL strings, such as quote characters inside strings. Now, if the entire SQL string were also considered binary data, meaning length-counted and not null-terminated, then the parser could continue to behave as it did before, where for example only quote characters are escaped and everything else isn't, and most unusual characters are simply disallowed except in literal values. By no means make a null double for a whitespace character. This assumes the parser handles all of its tokens as binary data rather than null-delimited data too. In the interest of simplicity, the updated SQLite programmer API would also take all of its input and output values in binary form such that the first few octets give length and/or other metadata and the actual data is not terminated. As for applications using the library that expect a null-terminated API, a simple wrapper over the new binary API could accomplish that; this would add or strip trailing nulls or leading metadata, and it would also implement the binary_escape et al functions. This last part in particular, the all-binary core API, could be considered a more radical change than may have been already thought of. Or maybe not. But it is something that I would be happy to use. And also this may make the binding with interpreted environments like Parrot or Perl or whatever where it is normal behind the scenes for scalar data to not be null-terminated. Good day. -- Darren Duncan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
