Re: [HACKERS] serial type - Mailing list pgsql-hackers

From Thomas Lockhart
Subject Re: [HACKERS] serial type
Date
Msg-id 37DE6296.7E50B1AF@alumni.caltech.edu
Whole thread Raw
In response to Re: [HACKERS] serial type  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> The problem is with direct pointers in the parse tree: the column
> node has a list of constraint nodes attached to it, and the UNIQUE
> node in that list has a keys field that points at the column node.
> The node print routines try to recurse through this structure, and
> of course it's a never-ending recursion.
> BTW, it's not only SERIAL that causes the problem; plain old
>         create table z2 (f1 int4 unique);
> will crash the backend if you start psql with PGOPTIONS="-d5".

Sure. The same structure is used to represent column *and* table
constraints; in the table case there is a need to refer to a column
from within the structure since there is not explicit column context
from a parent to use.

btw, the following *does* work wrt printing the parse tree:

postgres=> create table tc (i int, unique(i));
NOTICE:  CREATE TABLE/UNIQUE will create implicit index        'tc_i_key' for table 'tc'
CREATE

I suppose I could add code to explicitly unlink UNIQUE constraints
from the column-specific constraints, *or* we could change the
structure used for column constraints. I'd prefer mucking with the
parse tree as shipped from gram.y as little as possible, of course,
but your point about trouble lurking with recursive structures is well
taken.

Suggestions?
                     - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Patch for user-defined C-language functions
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Status report: long-query-string changes