> Hmm, good points...perhaps the best way to approach this initially is to > make the collations pluggable and then, if the desire is there, add in > pluggable charsets at a later point. Either that, or limit the multiple > charset operations. For instance, don't allow introducers but do allow > the client to do SET NAMES. Don't allow CONVERT(charset1 TO charset2) > but do allow indexes to be stored in a specific charset, etc. > > The simplicity we've reached from narrowing to only support UTF8 is > mainly maninfested in reduction of the parser and if adding pluggable > charsets back into the server increases the complexity of the parser > again, it's going to be a tough sell, particularly to Brian (and me and > others..)
Is there any benefit to making the server handle only a single charset, and determining that at compile time? Ship with UTF8 by default; users from Iran or other places that really benefit from a national charset can build their own and halve their storage space. I'm totally pulling this out of my nether regions, because I have no idea if this is actually easier or simpler to do. _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
