Received: from trends.net (root@clio.trends.ca [209.47.148.2])
	by hub.org (8.9.2/8.9.1) with ESMTP id OAA00541
	for <pgsql-interfaces@postgresql.org>;
	Sun, 14 Feb 1999 14:21:33 -0500 (EST)
	(envelope-from matthew@venux.net)
Received: from redbox.venux.net (redbox.venux.net [216.47.238.10])
	by trends.net (8.8.8/8.8.8) with ESMTP id OAA11907
	for <pgsql-interfaces@postgreSQL.org>;
	Sun, 14 Feb 1999 14:07:59 -0500 (EST)
Received: from thunder (net177138.hcv.com [209.153.177.138])
	by redbox.venux.net (Postfix) with SMTP
	id 2C3AA2E20D; Sun, 14 Feb 1999 14:08:06 -0500 (EST)
Message-Id: <4.1.19990214140611.00950100@mail.venux.net>
X-Sender: mhagerty@mail.venux.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sun, 14 Feb 1999 14:09:18 -0500
To: Tom Lane <tgl@sss.pgh.pa.us>
From: Matthew Hagerty <matthew@venux.net>
Subject: Re: [INTERFACES] (libpq question) Holy cow, what's all this fluff?! 
Cc: pgsql-interfaces@postgresql.org
In-Reply-To: <7750.919017918@sss.pgh.pa.us>
References: <Your message of Sun, 14 Feb 1999 00:17:59 -0500
	<4.1.19990214001552.009894c0@mail.venux.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 01:45 PM 2/14/99 -0500, Tom Lane wrote:
>Matthew Hagerty <matthew@venux.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

The docs that mention the performance hit were really the FAQ, item 3.10.
Check it out.  Also, item 3.8 mentions psql's \do command, however when I
type \do nothing happens and I have to ctrl-c to get the prompt back.  Any
suggestions?  All I need to do is a case-insensitive query.

Thanks,
Matthew