Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-general by date

Next:From: LewDate: 2008-08-31 16:14:45
Subject: Re: DUPS in tables columns ERROR: column ". . . " does not exist
Previous:From: Stanislav RaskinDate: 2008-08-31 16:04:52
Subject: Re: query with offset stops using index scan

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group