Received: from trends.net (root@clio.trends.ca [209.47.148.2]) by hub.org (8.9.2/8.9.1) with ESMTP id OAA00568 for ; Sun, 14 Feb 1999 14:21:40 -0500 (EST) (envelope-from tgl@sss.pgh.pa.us) Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by trends.net (8.8.8/8.8.8) with ESMTP id NAA11375 for ; Sun, 14 Feb 1999 13:45:54 -0500 (EST) Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id NAA07752; Sun, 14 Feb 1999 13:45:18 -0500 (EST) To: Matthew Hagerty cc: pgsql-interfaces@postgresql.org Subject: Re: [INTERFACES] (libpq question) Holy cow, what's all this fluff?! In-reply-to: Your message of Sun, 14 Feb 1999 00:17:59 -0500 <4.1.19990214001552.009894c0@mail.venux.net> Date: Sun, 14 Feb 1999 13:45:18 -0500 Message-ID: <7750.919017918@sss.pgh.pa.us> From: Tom Lane Matthew Hagerty 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