Re: [HACKERS] serial type

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

Responses

Browse pgsql-hackers by date

  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?