Re: ERROR: relation . . . does not exist

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

In response to

Browse pgsql-general by date

  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