Brian Aker wrote:
Hi!
On Sep 11, 2008, at 11:38 AM, Jim Starkey wrote:
Cast is a standard and useful feature for forcing conversions. I see
no purpose for Convert with a single internal character set.
A lot of the "2" + 2 stuff we do automatically, so convert() is less
useful (though I will full acknowledge that some of the auto
conversion is too friendly).
I'm all in favor of auto conversion and all that, but sometimes a
retrieval like
select cast (string_field as date) from someplace
is useful for debugging. I imagine there's a legitimate use for it as
well...
Could somebody say something about the general philosophy for
collations? How do they interact with comparisons?
The only thing that comes to mind is "A" == "a", aka case, also umlaut
vs non-umlaut characters for other languages. So it is not only a
question of sort, but in doing comparison to names.
The "SELECT BINARY a = A" stuff I find questionable. What does it even
mean to sort a BLOB for instance?
It makes as much sense to sort a binary blob as it does to sort a field
declared as bytes. (Disclosure: Falcon does not sort blobs for the
reason implicit in Brian's post.)
My thinking about blobs has changed. Blobs originally were an escape
from fixed length SQL types. Now that I've abandoned fixed length SQL
types, the utility of blob as a declared type diminishes to about
nothing. Nimbus will retain clob/blob types to humor the traditional,
but they will (probably) be synonyms for string and bytes,
respectively. There will still be a storage type for blobs, but it will
be dynamic, based on a length threshold. (Why, I can hear you asking?
Simple: There is no point to slop around a high-res jpeg to update a
last_reference column in the same row.)
--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
