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