Remove unused TODO.detail files.

doc/TODO.detail/default

-From tgl@sss.pgh.pa.us Sun May 23 18:59:22 1999
-Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6])
-	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id SAA08491
-	for <maillist@candle.pha.pa.us>; Sun, 23 May 1999 18:59:21 -0400 (EDT)
-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 SAA27952;
-	Sun, 23 May 1999 18:58:53 -0400 (EDT)
-To: Bruce Momjian <maillist@candle.pha.pa.us>
-cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
-Subject: Re: [HACKERS] DEFAULT fixed 
-In-reply-to: Your message of Sat, 22 May 1999 21:12:19 -0400 (EDT) 
-             <199905230112.VAA13489@candle.pha.pa.us> 
-Date: Sun, 23 May 1999 18:58:52 -0400
-Message-ID: <27950.927500332@sss.pgh.pa.us>
-From: Tom Lane <tgl@sss.pgh.pa.us>
-Status: ROr
-
-Actually, it's not as fixed as all that...
-
-create table foo1 (a char(5) default '', b int4);
-insert into foo1 (b) values (334);
-select * from foo1;
-a    |  b
------+---
-     |334
-(1 row)
-
-Good, the basic case is fixed, but:
-
-create table foo2 (a char(5) default text '', b int4);
-insert into foo2 (b) values (334);
-select * from foo2;
-a| b
--+--
- |16
-(1 row)
-
-Ooops.
-
-What you seem to have done is twiddle the handling of DEFAULT clauses
-so that the value stored for the default expression is pre-coerced to the
-column type.  That's good as far as it goes, but it fails in cases where
-the stored value has to be of a different type.
-
-My guess is that what *really* ought to happen here is that
-transformInsertStmt should check the type of the value it's gotten from
-the default clause and apply coerce_type if necessary.
-
-Unless someone can come up with a less artificial example than the one
-above, I'm inclined to leave it alone for 6.5.  This is the same code
-area that will have to be redone to fix the INSERT ... SELECT problem
-I was chasing earlier today: coercion of the values produced by SELECT
-will have to wait until the tail end of transformInsertStmt, and we
-might as well make wrong-type default constants get fixed in the same
-place.  So I'm not eager to write some throwaway code to patch a problem
-that no one is likely to see in practice.  What's your feeling about it?
-
-			regards, tom lane
-

doc/TODO.detail/fsync

-From owner-pgsql-general@hub.org Fri Dec 18 06:31:23 1998
-Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
-	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id GAA05554
-	for <maillist@candle.pha.pa.us>; Fri, 18 Dec 1998 06:31:21 -0500 (EST)
-Received: from hub.org (majordom@hub.org [209.47.145.100]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id EAA21127 for <maillist@candle.pha.pa.us>; Fri, 18 Dec 1998 04:46:38 -0500 (EST)
-Received: from localhost (majordom@localhost)
-	by hub.org (8.9.1/8.9.1) with SMTP id EAA01409;
-	Fri, 18 Dec 1998 04:44:19 -0500 (EST)
-	(envelope-from owner-pgsql-general@hub.org)
-Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Fri, 18 Dec 1998 04:43:22 +0000 (EST)
-Received: (from majordom@localhost)
-	by hub.org (8.9.1/8.9.1) id EAA01093
-	for pgsql-general-outgoing; Fri, 18 Dec 1998 04:43:18 -0500 (EST)
-	(envelope-from owner-pgsql-general@postgreSQL.org)
-Received: from dune.krs.ru (dune.krs.ru [195.161.16.38])
-	by hub.org (8.9.1/8.9.1) with ESMTP id EAA01067
-	for <pgsql-general@postgreSQL.org>; Fri, 18 Dec 1998 04:43:09 -0500 (EST)
-	(envelope-from vadim@krs.ru)
-Received: from krs.ru (localhost.krs.ru [127.0.0.1])
-	by dune.krs.ru (8.8.8/8.8.7) with ESMTP id QAA16201;
-	Fri, 18 Dec 1998 16:41:44 +0700 (KRS)
-	(envelope-from vadim@krs.ru)
-Message-ID: <367A2354.E998763@krs.ru>
-Date: Fri, 18 Dec 1998 16:41:40 +0700
-From: Vadim Mikheev <vadim@krs.ru>
-Organization: OJSC Rostelecom (Krasnoyarsk)
-X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386)
-X-Accept-Language: ru, en
-MIME-Version: 1.0
-To: Anton de Wet <adw@obsidian.co.za>
-CC: pgsql-general@postgreSQL.org
-Subject: Re: [GENERAL] Why PostgreSQL is better than other commerial softwares?
-References: <Pine.LNX.4.04.9812181046030.9458-100000@ra.obsidian.co.za>
-Content-Type: text/plain; charset=us-ascii
-Content-Transfer-Encoding: 7bit
-Sender: owner-pgsql-general@postgreSQL.org
-Precedence: bulk
-Status: RO
-
-Anton de Wet wrote:
-> 
-> >
-> > Often quick mailing list support?
-> 
-> :-)
-> 
-> While on the subject I finally found the solution to a problem I (and one
-> or two other people) posted about without answer. (So sometimes it's slow
-> mailing list support).
-> 
-> In importing about 5 million records (which I copy in blocks of 10000) the
-> copy became linearly slower. After a friend RTFM and refered me, I used
-> the -F switch (passed by the postmaster to the backend processes) and the
-> time became linear and a LOT shorter. Import time for the 5000000 records
-> now the same (or maybe even slightly faster, I didn't accurately time
-> them) as importing the data into oracle on the same machine.
-
-"While on the subject..." -:)
-
-This is the problem of buffer manager, known for very long time:
-when copy eats all buffers, manager begins write/fsync each
-durty buffer to free buffer for new data. All updated relations
-should be fsynced _once_ @ transaction commit. You would get
-the same results without -F...
-I still have no time to implement this -:(
-
-Vadim
-
-

doc/TODO.detail/null

-From owner-pgsql-general@hub.org Fri Oct  9 18:22:09 1998
-Received: from hub.org (majordom@hub.org [209.47.148.200])
-	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id SAA04220
-	for <maillist@candle.pha.pa.us>; Fri, 9 Oct 1998 18:22:08 -0400 (EDT)
-Received: from localhost (majordom@localhost)
-	by hub.org (8.8.8/8.8.8) with SMTP id SAA26960;
-	Fri, 9 Oct 1998 18:18:29 -0400 (EDT)
-	(envelope-from owner-pgsql-general@hub.org)
-Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Fri, 09 Oct 1998 18:18:07 +0000 (EDT)
-Received: (from majordom@localhost)
-	by hub.org (8.8.8/8.8.8) id SAA26917
-	for pgsql-general-outgoing; Fri, 9 Oct 1998 18:18:04 -0400 (EDT)
-	(envelope-from owner-pgsql-general@postgreSQL.org)
-X-Authentication-Warning: hub.org: majordom set sender to owner-pgsql-general@postgreSQL.org using -f
-Received: from gecko.statsol.com (gecko.statsol.com [198.11.51.133])
-	by hub.org (8.8.8/8.8.8) with ESMTP id SAA26904
-	for <pgsql-general@postgresql.org>; Fri, 9 Oct 1998 18:17:46 -0400 (EDT)
-	(envelope-from statsol@statsol.com)
-Received: from gecko (gecko [198.11.51.133])
-	by gecko.statsol.com (8.9.0/8.9.0) with SMTP id SAA00557
-	for <pgsql-general@postgresql.org>; Fri, 9 Oct 1998 18:18:00 -0400 (EDT)
-Date: Fri, 9 Oct 1998 18:18:00 -0400 (EDT)
-From: Steve Doliov <statsol@statsol.com>
-X-Sender: statsol@gecko
-To: pgsql-general@postgreSQL.org
-Subject: Re: [GENERAL] Making NULLs visible.
-Message-ID: <Pine.GSO.3.96.981009181716.545B-100000@gecko>
-MIME-Version: 1.0
-Content-Type: TEXT/PLAIN; charset=US-ASCII
-Sender: owner-pgsql-general@postgreSQL.org
-Precedence: bulk
-Status: RO
-
-On Fri, 9 Oct 1998, Bruce Momjian wrote:
-
-> [Charset iso-8859-1 unsupported, filtering to ASCII...]
-> > > Yes, \ always outputs as \\, excepts someone changed it last week, and I
-> > > am requesting a reversal.  Do you like the \N if it is unique?
-> > 
-> > Well, it's certainly clear, but could be confused with \n (newline). Can we
-> > have \0 instead?
-> 
-> Yes, but it is uppercase.  \0 looks like an octal number to me, and I
-> think we even output octals sometimes, don't we?
-> 
-
-my first suggestion may have been hare-brained, but why not just make the
-specifics of the output user-configurable.  So if the user chooses \0, so
-be it, if the user chooses \N so be it, if the user likes NULL so be it.
-but the option would only have one value per database at any given point
-in time.  so database x could use \N on tuesday and NULL on wednesday, but
-database x could never have two references to the characters(s) used to
-represent a null value.
-
-steve
-
-
-
-
-From owner-pgsql-general@hub.org Sun Oct 11 17:31:08 1998
-Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
-	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id RAA20043
-	for <maillist@candle.pha.pa.us>; Sun, 11 Oct 1998 17:31:02 -0400 (EDT)
-Received: from hub.org (majordom@hub.org [209.47.148.200]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id RAA03069 for <maillist@candle.pha.pa.us>; Sun, 11 Oct 1998 17:10:34 -0400 (EDT)
-Received: from localhost (majordom@localhost)
-	by hub.org (8.8.8/8.8.8) with SMTP id QAA10856;
-	Sun, 11 Oct 1998 16:57:34 -0400 (EDT)
-	(envelope-from owner-pgsql-general@hub.org)
-Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sun, 11 Oct 1998 16:53:35 +0000 (EDT)
-Received: (from majordom@localhost)
-	by hub.org (8.8.8/8.8.8) id QAA10393
-	for pgsql-general-outgoing; Sun, 11 Oct 1998 16:53:34 -0400 (EDT)
-	(envelope-from owner-pgsql-general@postgreSQL.org)
-X-Authentication-Warning: hub.org: majordom set sender to owner-pgsql-general@postgreSQL.org using -f
-Received: from mail1.panix.com (mail1.panix.com [166.84.0.212])
-	by hub.org (8.8.8/8.8.8) with ESMTP id QAA10378
-	for <pgsql-general@postgreSQL.org>; Sun, 11 Oct 1998 16:53:28 -0400 (EDT)
-	(envelope-from tomg@admin.nrnet.org)
-Received: from mailhost.nrnet.org (root@mailhost.nrnet.org [166.84.192.39])
-	by mail1.panix.com (8.8.8/8.8.8/PanixM1.3) with ESMTP id QAA16311
-	for <pgsql-general@postgreSQL.org>; Sun, 11 Oct 1998 16:53:24 -0400 (EDT)
-Received: from admin.nrnet.org (uucp@localhost)
-          by mailhost.nrnet.org (8.8.7/8.8.4) with UUCP
-   id QAA16345 for pgsql-general@postgreSQL.org; Sun, 11 Oct 1998 16:28:47 -0400
-Received: from localhost (tomg@localhost)
-	by admin.nrnet.org (8.8.7/8.8.7) with SMTP id QAA11569
-	for <pgsql-general@postgreSQL.org>; Sun, 11 Oct 1998 16:28:41 -0400
-Date: Sun, 11 Oct 1998 16:28:41 -0400 (EDT)
-From: Thomas Good <tomg@admin.nrnet.org>
-To: pgsql-general@postgreSQL.org
-Subject: Re: [GENERAL] Making NULLs visible.
-In-Reply-To: <Pine.GSO.3.96.981009181716.545B-100000@gecko>
-Message-ID: <Pine.LNX.3.96.981011161908.11556A-100000@admin.nrnet.org>
-MIME-Version: 1.0
-Content-Type: TEXT/PLAIN; charset=US-ASCII
-Sender: owner-pgsql-general@postgreSQL.org
-Precedence: bulk
-Status: RO
-
-Watching all this go by...as a guy who has to move alot of data
-from legacy dbs to postgres, I've gotten used to \N being a null.
-
-My vote, if I were allowed to cast one, would be to have one null 
-and that would be the COPY command null.  I have no difficulty
-distinguishing a null from a newline...
-
-At the pgsql command prompt I would find seeing \N rather reassuring.
-I've seen alot of these little guys.
-
-    ---------- Sisters of Charity Medical Center ----------
-                   Department of Psychiatry
-                            ----     
-    Thomas Good                          <tomg@q8.nrnet.org>
-    Coordinator, North Richmond C.M.H.C. Information Systems
-    75 Vanderbilt Ave, Quarters 8        Phone: 718-354-5528
-    Staten Island, NY   10304            Fax:   718-354-5056
-
-
-

doc/TODO.detail/pg_shadow

-From owner-pgsql-hackers@hub.org Sun Aug  2 20:01:13 1998
-Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
-	by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id UAA15937
-	for <maillist@candle.pha.pa.us>; Sun, 2 Aug 1998 20:01:11 -0400 (EDT)
-Received: from hub.org (hub.org [209.47.148.200]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id TAA01026 for <maillist@candle.pha.pa.us>; Sun, 2 Aug 1998 19:33:53 -0400 (EDT)
-Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id TAA19878; Sun, 2 Aug 1998 19:30:59 -0400 (EDT)
-Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sun, 02 Aug 1998 19:28:23 +0000 (EDT)
-Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id TAA19534 for pgsql-hackers-outgoing; Sun, 2 Aug 1998 19:28:22 -0400 (EDT)
-Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org (8.8.8/8.7.5) with ESMTP id TAA19521 for <pgsql-hackers@postgreSQL.org>; Sun, 2 Aug 1998 19:28:15 -0400 (EDT)
-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 TAA22594
-	for <pgsql-hackers@postgreSQL.org>; Sun, 2 Aug 1998 19:28:13 -0400 (EDT)
-To: pgsql-hackers@postgreSQL.org
-Subject: [HACKERS] TODO item: make pg_shadow updates more robust
-Date: Sun, 02 Aug 1998 19:28:13 -0400
-Message-ID: <22591.902100493@sss.pgh.pa.us>
-From: Tom Lane <tgl@sss.pgh.pa.us>
-Sender: owner-pgsql-hackers@hub.org
-Precedence: bulk
-Status: ROr
-
-I learned the hard way last night that the postmaster's password
-authentication routines don't look at the pg_shadow table.  They
-look at a separate file named pg_pwd, which certain backend operations
-will update from pg_shadow.  (This is not documented in any user
-documentation that I could find; I had to burrow into
-src/backend/commands/user.c to discover it.)
-
-Unfortunately, if a clueless dbadmin (like me ;-)) tries to update
-password data with the obvious thing,
-	update pg_shadow set passwd = 'xxxxx' where usename = 'yyyy';
-pg_pwd doesn't get fixed.
-
-A more drastic problem is that pg_dump believes it can save and
-restore pg_shadow data using "copy".  Following an initdb and restore
-from a pg_dump -z script, pg_shadow will look just fine, but only
-the database admin will be listed in pg_pwd.  This is likely to provoke
-some confusion, IMHO.
-
-As a short-term thing, the fact that you *must* set passwords with
-ALTER USER ought to be documented, preferably someplace where a
-dbadmin who's never heard of ALTER USER is likely to find it.
-
-As a longer-term thing, I think it would be far better if ordinary
-SQL operations on pg_shadow just did the right thing.  Wouldn't it
-be possible to implement copying to pg_pwd by means of a trigger on
-pg_shadow updates, or something like that?
-
-(I'm afraid that pg_dump -z is pretty well broken for operations on
-a password-protected database, btw.  Has anyone used it successfully
-in that situation?)
-
-			regards, tom lane
-
-