Re: failed to lookup type 0
От | Tom Lane |
---|---|
Тема | Re: failed to lookup type 0 |
Дата | |
Msg-id | 21911.1071262874@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: failed to lookup type 0 ("Vernon Smith" <vwu98034@lycos.com>) |
Список | pgsql-bugs |
"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
В списке pgsql-bugs по дате отправления: