Skip site navigation (1) Skip section navigation (2)

Re: [INTERFACES] Wierd error when creating a table...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alex Turner <aturner(at)maaco(dot)com>
Cc: "pgsql-interfaces(at)postgreSQL(dot)org" <pgsql-interfaces(at)postgreSQL(dot)org>
Subject: Re: [INTERFACES] Wierd error when creating a table...
Date: 1999-05-27 20:54:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-interfaces
Alex Turner <aturner(at)maaco(dot)com> writes:
> When I try to create a table where the primary key is set to be a column
> that is of type int8 or int28 it complains giving me the following
> error:

> ERROR:  Can't find a default operator class for type 22.

Postgres 6.4 doesn't have support for indexes on int8 fields (but 6.5
does).  There is no support for indexes on int28 in either release.

> If I try to define the table again, it tells me that the relation
> already exists, yet it doesnt who up on the table list when I hit \d in
> psql.

That's a bug: the physical file for the relation has already been
created by the time the failure in creating the index occurs, and
although all the updates to system tables get backed out, the empty
file is not removed during the transaction abort.  So the table is
not there as far as any subsequent SQL commands are concerned, but
CREATE TABLE is (very properly IMHO) unwilling to overwrite any
random file it finds in the database directory.

You can reach into the data/base/YOURDB/ directory and delete the file
by hand.

I believe fixing this is on the TODO list, but I see that the bug is
still there in 6.5-current.  Something we might be able to squeeze in
for 6.5 is a more helpful error message ("I don't want to overwrite
file thus-and-so, delete it by hand if you are sure it's OK...").

			regards, tom lane

pgsql-interfaces by date

Next:From: Mark GrimseyDate: 1999-05-27 21:12:51
Subject: Oracle and Postgresql
Previous:From: Tom LaneDate: 1999-05-27 20:44:47
Subject: Re: [INTERFACES] Re: [GENERAL] JDBC and insert - stack overflow

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group