John Machin wrote: > Assuming your guid is a BLOB, then > SELECT other_stuff, QUOTE(guid), etc > will display it as hex e.g. X'01020304' > This is great; now I can see them at least!
>> P.S. Of course even better would be the ability to read/write GUIDs as >> properly formatted strings! (Note: I am not asking that they be treated >> internally as anything other than a binary chunk of data -- just the >> text form being changed). >> > > On output, how do you expect it to determine what blobs are guids? > column_name like '%guid%' ?? > Yes...is that a problem? I have not really looked at the SQLite code much. I know it remembers the declared types and assigns appropriate internal types. My thinking was that for certain types (GUID, UUID, maybe even Datetime/timestamp etc) it, or the user, could (optionally, for backward compatibility) assign 'toString' and 'fromString' operators. ie. not promote the to full types, but assign them a quasi-type status. In the case of dates, for example, it would allow me to enter '1-Jan-1970' and fromString would produce '1970-01-01'. In the case of GUIDs, it would display and load them in the standard GUID representation. This would not even necessarily need to form part of the standard sqlite code, but could be done as plugable functions. But, as I said, I have not really looked much at sqlite internals to know if this is completely impractical. > On input: does the SQL standard define a guid literal? > No; but GUIDs do. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
