From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Simms <grim(at)argh(dot)demon(dot)co(dot)uk>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] serial type |
Date: | 1999-09-14 14:16:46 |
Message-ID: | 37DE58CE.CA64B35F@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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.
If I understand the problem correctly, the "column name" field in the
constraint clause attached to the column node is being used to look up
the column node, resulting in a recursive infinite loop. Or is
something else happening with direct pointers back to a parent node?
The CONSTR_UNIQUE node travels from gram.y to analyze.c attached to
the column node (it can also be specified as a table constraint, and
is attached elsewhere for that case). Within transformCreateStmt(), I
scan through these constraint nodes, filling in missing info, and
collecting them in a "deferred list" to look at later in the same
routine. I don't detach the constraint nodes from the column nodes at
that time, though it might be possible to do so.
Can you clarify the problem for me? I'm afraid that I didn't pay
enough attention to the thread :(
- Thomas
--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-09-14 14:25:32 | Re: [HACKERS] Performance of MIN() and MAX() |
Previous Message | Theo Kramer | 1999-09-14 14:03:17 | Re: [HACKERS] ISO dates with European Format |