Re: [HACKERS] Unable to create tables...
| От | Don Baccus |
|---|---|
| Тема | Re: [HACKERS] Unable to create tables... |
| Дата | |
| Msg-id | 3.0.1.32.19990806125933.00e02428@mail.pacifier.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Unable to create tables... ("Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>) |
| Список | pgsql-hackers |
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 Serviceand other goodies at http://donb.photo.net.
В списке pgsql-hackers по дате отправления: