Re: [HACKERS] serial type
От | Thomas Lockhart |
---|---|
Тема | Re: [HACKERS] serial type |
Дата | |
Msg-id | 37DE58CE.CA64B35F@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] serial type (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] serial type
|
Список | 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@alumni.caltech.edu South Pasadena, California
В списке pgsql-hackers по дате отправления: