Echoing some others' responses, particularly Darren's:
1. I don't see the rationale for putting much priority on
multiple string encodings. After all, blobs still can't
be stored natively :).
UTF-16 adds extra complexity, because of embedded nulls,
and because of its own need for a byte-order-mark (BOM).
Furthermore, it is not a fixed width encoding.
(Java, and Windows prior to win2k, behaved as it if it was
fixed length, by neglecting surrogate pairs, but they are
just broken.)
UTF-8 is not a fixed width encoding either, but it does
not have embedded nulls, and it is supported "natively" by
practically all scripting languages.
The wchar_t issue is a pain; on Windows it is typically
a 16-bit type, and on Unix it is typically 32-bit, and in
either case you still don't know whether it is UCS-2, UTF-16,
or (on unix) UCS-4.
But using a char* declaration for a string that can contain
embedded nulls is an invitation to rampant bugs, IMHO.
2. I would be very interested to hear more about better
concurrency support, particularly along the lines of
the HUT HiBase/Shades ideas.
Doug Currie has written up some ideas about this in
cvstrac ("BlueSky"), but I'd also urge people to read
the HUT papers. At least K. Oksanen's publications are
still online at http://hibase.cs.hut.fi/publications.shtml
3. I'm unsure what is driving a desire for variable typing
among the values of a single column. Is this some deep-seated
distaste for the relational model :).
-mda
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
