"Vernon Smith" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
