Received: from u1.abs.net (root@u1.abs.net [207.114.0.131]) by hub.org (8.8.8/8.7.5) with ESMTP id QAA07488 for ; Mon, 23 Mar 1998 16:25:57 -0500 (EST) Received: from insightdist.com (nobody@localhost) by u1.abs.net (8.8.5/8.8.5) with UUCP id PAA15530 for pgsql-hackers@postgresql.org; Mon, 23 Mar 1998 15:58:28 -0500 (EST) X-Authentication-Warning: u1.abs.net: nobody set sender to insightdist.com!darrenk using -f Received: by insightdist.com (AIX 3.2/UCB 5.64/4.03) id AA20077; Mon, 23 Mar 1998 15:40:12 -0500 Received: by ceodev (AIX 4.1/UCB 5.64/4.03) id AA48906; Mon, 23 Mar 1998 15:39:11 -0500 Date: Mon, 23 Mar 1998 15:39:11 -0500 From: darrenk@insightdist.com (Darren King) Message-Id: <9803232039.AA48906@ceodev> To: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] char types gone. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: 1RjADdt3LjPz3njzSe5mkA== > > Have managed to delete char2,4,8 and 16. > > Three points now...regression tests, docs and interfaces. > > > > 1. Regression tests make very extensive use of char16. Seems to > > me that these should be changed to a name. Same for tutorial and > > any other example references in the code. Seem ok? > > Any reason not to use "text" for these cases? Or even varchar()? "name" > is probably really only an internal Postgres type. We should have a > regression test for it if we don't already. Let me know if you want me > to help... I think the 'name' type should be considered an internal type only and mentioned as such wherever it is documented. It's only purpose seems to be for a consistent length to internal names and it does that rather well. User's would be better served with the other, varlena-based, types. Any examples I was going to convert from char16 to char(16). There are a couple of mentions of the char16 struct that will have to be integrated or changed to reference the varlena struct. Finally, I'm redoing the char16 regression test for name. > > 2. I'll take my best shot at the docs. > > Where? The man pages or the sgml sources? I'm shooting for getting the > sgml sources right, and obsoleting the man page _sources_, regenerating > them from the sgml instead. Do you want patches against doc/src/sgml/*? The man pages references were few, so they were easy to change for consistency sake then til they drop into the bit bucket. Changed a few references in the userguide too. Only have to tidy up the docs and I'll submit the patch. darrenk