From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Matthew Hagerty <matthew(at)venux(dot)net> |
Cc: | pgsql-interfaces(at)postgresql(dot)org |
Subject: | Re: [INTERFACES] (libpq question) Holy cow, what's all this fluff?! |
Date: | 1999-02-14 18:45:18 |
Message-ID: | 7750.919017918@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
Matthew Hagerty <matthew(at)venux(dot)net> writes:
> At 04:30 AM 2/14/99 +0000, Thomas G. Lockhart wrote:
>>> You want a varchar (or is it bpchar?), not a char. char(x) will always
>>> return x characters, with space padding if necessary.
> Yeah, but the docs say you get a performance hit for using varchar, text,
> and the like. Which is worse, the database performance hit or the extra
> call to trim for every char field?
Whatever docs you are looking at are obsolete. char(n), varchar(n), and
text have essentially interchangeable performance and representation.
They all have a length word and some characters.
(I've griped about that myself --- particularly that plain "char" is
effectively an 8-byte field, not a 1-byte field like you'd expect.
Nobody else seems worried about it though.)
I'd recommend using "text", personally, unless you have a specific
reason for imposing an upper length limit on the string.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ken J. Wright | 1999-02-14 19:04:56 | ODBC authentication failure |
Previous Message | Goda Attila | 1999-02-14 15:01:49 | ODBC and wxWindows |