From: | Lew <noone(at)lwsc(dot)ehost-services(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: ERROR: relation . . . does not exist |
Date: | 2008-08-31 16:06:53 |
Message-ID: | 2-SdnbAv674AXCfVnZ2dnUVZ_r6dnZ2d@comcast.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Albretch Mueller wrote:
>> Varchar or text?
> ~
> Is the length of the data read in always less than 255 bytes ( or
> characters?)? ...
It may be more limited than that by application-domain-specific constraints -
e.g., a license plate might be statutorily limited to eight characters.
It might be coincidence that the input happens to fit within 255 characters
when future inputs might not. One cannot make certain statements about
whether "data read in always [being] less than 255 ... characters" based on a
limited sample set, only probabilistic ones, absent reasoning about the
application domain.
Additionally, one could use TEXT for shorter columns if one wanted:
> There are no performance differences between these three types,
[character varying(n), character(n) and text]
> apart from increased storage size when using the blank-padded
> type, and a few extra cycles to check the length when storing
> into a length-constrained column. While character(n) has
> performance advantages in some other database systems, it has
> no such advantages in PostgreSQL. In most situations text or
> character varying should be used instead.
<http://www.postgresql.org/docs/8.3/static/datatype-character.html>
DBMSes are about schemata and planning the data structures, not loosey-goosey
typing. (This reminds me of the debate between the loosely-typed language
(e.g., PHP) camp versus the strongly-typed language (C#, Java) camp.) Schemas
are based on analysis of and reasoning about the application domain, not lucky
guesses about a limited sample of inputs.
--
Lew
From | Date | Subject | |
---|---|---|---|
Next Message | Lew | 2008-08-31 16:14:45 | Re: DUPS in tables columns ERROR: column ". . . " does not exist |
Previous Message | Stanislav Raskin | 2008-08-31 16:04:52 | Re: query with offset stops using index scan |