On 2008-02-12 19:39, Ken Johanson wrote:
> Dean Gibson (DB Administrator) wrote:
>> On 2008-02-12 16:17, Ken Johanson wrote:
>>> Dean Gibson (DB Administrator) wrote:
>>> ...
>>>
>>> I'm guessing you declare an explicit length of 1 (for portability),
>>> or do you "CAST (x as char)"? And one might ask in what context we'd
>>> need CHAR(1) on a numeric type, or else if substr/ing or left() make
>>> the code more readable for other data types..
>>>
>>
>> Actually, I just write "CHAR" for a length of 1.
>
> On a numeric type?.. That's the quintessential part to me...
No, not on a numeric type. The database stores a single byte code from
a gov't DB. In a VIEW, I do a table lookup on the code and suffix an
English explanation of the code. However, some of the users of the VIEW
(eg, php) would like to do a SELECT based on the original value, and I
use CAST( ... AS CHAR ) to get just the original code back. I use the
CAST as a shorthand for SUBSTRING. I don't know if that is easier for
the planner to flatten than a function call, but it's easier (for me) to
read (especially if I use the PostgreSQL "::" cast extension).
>>> > What is wrong with using VARCHAR for your
>>> purpose????????????????????????????
>>>
>>> Simply that a commonly used database (my) does not support it.
>>
>> By "my", do you mean "MySQL", or "MyDatabase"? If the latter, then
>> while it's your business decision (and/or that of your customers),
>> the availability of decent, free databases should make a compelling
>> case for anyone using anything else, to migrate (and never look back)
>> to something full-featured.
> Yes, Mysql, and yes, it's customer driven.
>
Then I don't understand. While I've never used MySQL, the MySQL web
pages apparently indicate that VARCHAR has been supported since version
3.2: http://dev.mysql.com/doc/refman/4.1/en/char.html
--
Mail to my list address MUST be sent via the mailing list.
All other mail to my list address will bounce.
