From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Simms <grim(at)argh(dot)demon(dot)co(dot)uk> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org, Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
Subject: | Re: [HACKERS] serial type |
Date: | 1999-09-11 15:56:09 |
Message-ID: | 14863.937065369@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Simms <grim(at)argh(dot)demon(dot)co(dot)uk> writes:
> games=> create table game (
> games-> refnum serial
> games-> );
> NOTICE: CREATE TABLE will create implicit sequence 'game_refnum_seq' for SERIAL column 'game.refnum'
> NOTICE: CREATE TABLE/UNIQUE will create implicit index 'game_refnum_key' for table 'game'
> pqReadData() -- backend closed the channel unexpectedly.
> I set the debug to be -30 instead of its maximum of -3
Actually, 3 is not the maximum: 4 and 5 turn on dumping of parse and
plan trees.
What I find is that the parsetree dump attempt recurses infinitely,
because the parser is producing a parsetree with circular references.
The ColumnDef node for refnum has a list of constraints, and one of the
constraints is a CONSTR_UNIQUE node that has a keys list that points
right back at that same ColumnDef node. Try to dump it, and presto:
infinite recursion in the node print functions.
I am not sure if this is a mistake in the construction of the parsetree
(Thomas, what do you think?) or if the node print functions need to be
modified. I think it'd be easiest to alter the parsetree, though.
Perhaps the UNIQUE constraint ought to be attached somewhere else.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-09-11 17:57:46 | Fixing Simms' vacuum problems |
Previous Message | Tom Lane | 1999-09-11 15:34:28 | Re: [HACKERS] case bug? |