Re: failed to lookup type 0

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: vwu98034(at)lycos(dot)com
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: failed to lookup type 0
Date: 2003-12-12 21:01:14
Message-ID: 21911.1071262874@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Vernon Smith" <vwu98034(at)lycos(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Neil Conway 2003-12-13 01:27:17 Re: libpq3 + ssl memory leak
Previous Message Vernon Smith 2003-12-12 19:11:08 Re: failed to lookup type 0