Re: SELECT CAST(123 AS char) -> 1

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...

>
>> > 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.

>
> It's like requiring portable C code to use the old, pre-ANSI style of
> function declarations, because some old C compilers might not support
> the ANSI style.  I think Richard Stallman of the FSF takes that
> position, but I don't know of anyone else (although I'm sure there are
> exceptions).
>

Point taken. This is really just a rock and hard place because I'm stuck
between 3rd party products (customer API and database x^n). I'm trying
to convey here that changing the behavior to a (numb AS varchar) one,
practically speaking, is more benign/useful (vs now), even if that is
only a non-spec workaround, and "everyone else does it" is an invalid
arg. I'm much more concerned about the AS in column labels issue and
some driver todos. The pre standard_conforming_strings behavior used to
be the full show stopper for PG, and now I only hear smaller
compatibility and ease of migration concerns (whether spec or defacto).
Things are improving.