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.
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
