Thread: failed to lookup type 0

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

Vernon Smith wrote:
> 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

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

"Vernon Smith" <vwu98034@lycos.com> writes:
> 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

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

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

>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.

Joe Conway wrote
>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.


____________________________________________________________
Free Poetry Contest. Win $10,000. Submit your poem @ Poetry.com!
http://ad.doubleclick.net/clk;6750922;3807821;l?http://www.poetry.com/contest/contest.asp?Suite=A59101

"Vernon Smith" <vwu98034@lycos.com> writes:
> Thanks both for your response. Here is a screen shot with the table
> definition and reproducible example:

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