Message-Id: <3.0.1.32.19990806125933.00e02428@mail.pacifier.com>
Date: Fri, 06 Aug 1999 12:59:33 -0700
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Unable to create tables...
Cc: Postgres Hackers List <hackers@postgreSQL.org>
In-Reply-To: <19990806144638.A17288@wallace.ece.rice.edu>
References: <3.0.1.32.19990806115431.00e087c8@mail.pacifier.com>
	<37AB25F0.CB67F617@wgcr.org> <37AAFF29.958CE9F2@alumni.caltech.edu>
	<3.0.1.32.19990806094228.00e0388c@mail.pacifier.com>
	<3.0.1.32.19990806112347.00e0d9b4@mail.pacifier.com>
	<3.0.1.32.19990806115431.00e087c8@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:46 PM 8/6/99 -0500, Ross J. Reedstrom wrote:

>Check to see if there are files in the pgsql/data/base/'yourdbname'
>directory called 'pgdump_oid' and 'foo'. Some situations lead to a table
>being almost completely deleted, but leaving the file behind. Doesn't
>explain the 'table still there' phenomena, but might let you recreate a
>'dropped' table.

Thanks, I thought of this one myself, and deleted "foo".  This is
when it got into the mode of allowing "create table foo..." and
an apparently successful "drop table foo", but with "foo" left
behind in pg_class (I think that's right) and "select count(*)
from foo" returning 0 rows (i.e. the relation really seems to
exist!)

>
>Ross
>P.S. once common problem is dropping a table doesn't always get all the
>objects created by 'convenience' types. For example, not not sure the 
>sequence created for a serial type gets dropped with its table. In fact,
>I'm pretty sure it doesn't (and, for now, shouldn't)

Yes, this isn't my problem, though.


- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.