From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Ken Johanson" <pg-user(at)kensystem(dot)com> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: SELECT CAST(123 AS char) -> 1 |
Date: | 2008-02-12 10:36:57 |
Message-ID: | 877ihapik6.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Ken Johanson" <pg-user(at)kensystem(dot)com> writes:
> Tom Lane wrote:
>
>> SQL92 section 6.1 <data type> quoth
>>
>> <character string type> ::=
>> CHARACTER [ <left paren> <length> <right paren> ]
>> | CHAR [ <left paren> <length> <right paren> ]
>>
>> ...
>>
>> 4) If <length> is omitted, then a <length> of 1 is implicit.
>>
>> Therefore, writing just "char" is defined as equivalent to "char(1)".
>
> However when length is not defined I think it will generally be safe(r) to
> auto-size. In the grand scheme auto-size creates much more sensible output than
> a 1-char wide one (even if right-padded to max char-length of the type).
Sure, but you're a prime candidate for understanding the value of following
the spec if you're trying to write software that works with multiple
databases.
It's a bit crazy to be using CHAR and then complaining about padding... That's
what CHAR is for. If the other database doesn't support varchar it's so far
from the SQL spec that writing something portable between it and something
else is probably hopeless.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2008-02-12 10:39:05 | Re: TSearch2 Migration Guide from 8.2 to 8.3 |
Previous Message | Oliver Weichhold | 2008-02-12 10:10:49 | TSearch2 Migration Guide from 8.2 to 8.3 |