When I try to delete data from one table, I get this error:

ERROR: get_typdefault: failed to lookup type 0

I can't find any reasons other than a bug. The PG version is 7.3.4


__________________________________________________ __________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Vernon Smith wrote:
And neither can we without some details.

Please post the results of
\d tablename
, the definitions of any trigger functions (particularly any "on delete"
triggers), and if possible a complete reproducible example.

Joe


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

"Vernon Smith" <vwu98034 (AT) lycos (DOT) com> writes:
You'll need to provide a self-contained test case.

We've seen bugs with similar symptoms associated with dropped columns,
but AFAIK they are all fixed in 7.3.4.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

Thanks both for your response. Here is a screen shot with the table definition and reproducible example:

mm=# \d signon
Table "public.signon"
Column | Type | Modifiers
---------+-----------------------+-----------
name | character varying(25) | not null
user_id | bigint | not null
passwd | character varying(30) | not null
Indexes: signon_pkey primary key btree (user_id),
signon_name_key unique btree (name)

mm=# insert into signon values ('dump',3434343,'wdp');
INSERT 256495 1
mm=# delete from signon where user_id='3434343';
ERROR: get_typdefault: failed to lookup type 0
mm=#

The version information is the following:

Welcome to psql 7.3.4, the PostgreSQL interactive terminal.

on cygwin with Window 2000.



Tom Lane wrote

Joe Conway wrote

__________________________________________________ __________
Free Poetry Contest. Win $10,000. Submit your poem @ Poetry.com!
http://ad.doubleclick.net/clk;675092...p?Suite=A59101

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

"Vernon Smith" <vwu98034 (AT) lycos (DOT) com> writes:
Sorry, but that doesn't qualify as a reproducible example, because
it works fine here:

regression=# create table signon(
regression(# name varchar(25) not null,
regression(# user_id bigint not null,
regression(# passwd varchar(30) not null,
regression(# primary key(user_id),
regression(# unique (name));
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index 'signon_pkey' for table 'signon'
NOTICE: CREATE TABLE / UNIQUE will create implicit index 'signon_name_key' for table 'signon'
CREATE TABLE
regression=# insert into signon values ('dump',3434343,'wdp');
INSERT 154109 1
regression=# delete from signon where user_id='3434343';
DELETE 1

Since I think this must be some kind of problem with a dropped column,
I tried adding and dropping some additional columns, but no joy.

A reproducible example will have to be one that lets someone else create
a table that behaves this way. We need the series of creation and
alteration commands that got you to this state.

BTW, I'm not sure how a DELETE command would invoke get_typdefault()
at all. I'm wondering if this table participates in any foreign
key constraints, which could possibly cause UPDATEs to be issued
against other tables, which would be plausible sources of
get_typdefault() calls.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings