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

Re: [QUESTIONS] varchar vs text

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: Dan Brickley <Daniel(dot)Brickley(at)Bristol(dot)ac(dot)uk>, Postgres Hackers List <hackers(at)postgresql(dot)org>
Subject: Re: [QUESTIONS] varchar vs text
Date: 1998-03-01 21:28:56
Message-ID: 34F9D317.DB96E2A7@alumni.caltech.edu (view raw or flat)
Thread:
Lists: pgsql-hackers
> > > Varchar currently (in 6.2.1 and below) takes up the entire length specified
> > > in the definition, despite the fact the value in it may actually be
> > > shorter. Text takes only the space taken by the value.
> >
> > Thanks for the clarification. In this case, what happens with varchar's
> > length if the original definition for that field leaves length undefined?
> > Does it behave like text in that case?
>
> You really shouldn't be doing that.  Not sure what happens.  Not a good
> idea:
>
>         create table test (x varchar);

?? This was defined to be a varchar of unlimited length, much like, or identical
to, text. Should this now be disallowed? If so, we can fix the parser to disallow
it so people don't get misled.

> > I also vaguely recall seeing a message last year about the use of indexes
> > in queries: that in [some circumstances] indexes built on varchar fields
> > don't get used and a sequential scan through all records takes place
> > instead. Is there any distinction between varchar and text here?
>
> Don't remember that.

This was probably Bruce's improvements to allow indices on some pattern matching.
Doesn't make a distinction between these types in its behavior.

                                                  - Tom


Responses

pgsql-hackers by date

Next:From: Thomas G. LockhartDate: 1998-03-01 21:32:16
Subject: Re: [QUESTIONS] varchar vs text
Previous:From: Bruce MomjianDate: 1998-03-01 21:23:32
Subject: Look at pgsql/doc/postgres.tar.gz

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