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

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

In response to

Responses

Browse pgsql-general by date

  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