On Thu, 1 Dec 2005, Nathan Kurz wrote: > On Thu, Dec 01, 2005 at 10:13:24AM -0500, Matt Sergeant wrote: > > On 30 Nov 2005, at 17:59, Nathan Kurz wrote: > > > > >The Perl interface through DBD-SQLite-1.09 is broken with regard to > > >blobs. It binds the result as text, thus doesn't handle NUL's. > > > > This is nonsense. The perl interface is just fine with regard to blobs > > - there's even a test suite for it. > > I apologize if I've offended you, but I think your response is a bit > harsh. I'll try to be more specific as to how I might consider it to > be broken, even if this isn't the word you would choose. While it > certainly works in some cases (including those in the test suite) I > don't think it works in all the cases it could or should. > > Inserting blobs works fine if one uses "$sth->bind_param(1, $blob, > SQL_BLOB)" as in the test. It does not work if one merely uses > "$sth->execute($blob)". While I can see that this might be behaviour > as designed, it temporarily stumped me when I first starting using it, > and searching the web I found several others stumped by it as well. > The poster to the list presumably was having the same problem. > > Looking now at the DBI documentation, I see that values bound using > execute are 'usually treated as "SQL_VARCHAR" types unless the driver > can determine the correct type (which is rare)'. Because it is simple > to scan the string for NUL's, I guess I consider this one of those > rare cases where the driver can just 'do the right thing'.
It's pointless though to do that, because then when they try and get data out the same way they won't understand why it's truncated. At least this way they have to bind properly on both in and out. It's just a weakness of the weak type system that sqlite uses that means it has to be this way. I'm sorry if that's undesirable but that's the way it is. If I went the other route, and treated everything as blobs (unless explicitly bound as VARCHAR) then you would get weird results trying to do things in SQL that assume strings, particularly with unicode data. > For the second patch I offered, I think I'm on firmer ground. I don't > think it is currently possible to return NUL containing data from a > user defined function. Attached is a patch to 08create_function.t to > test for this. It fails with the released version, but works with my > patched version. While I think my patch is 'safe', I would happily > agree that there might be a more elegant solution. I'll have to look again. My time is currently under great strain, and my mac just pretty much wiped itself so I've lost 2 days to a restore. > Thanks for your work in creating this interface! I don't mean to > sound ungrateful for it. No problem. For the first issue I'd be really happy to accept a documentation patch - that's where I feel the blob support is weak :-) ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
