Re: [HACKERS] serial type
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] serial type |
Дата | |
Msg-id | 16320.937319984@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] serial type (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
Список | pgsql-hackers |
Thomas Lockhart <lockhart@alumni.caltech.edu> writes: >> 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 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 oldcreate table z2 (f1 int4 unique); will crash the backend if you start psql with PGOPTIONS="-d5". As I said, I'm not sure if the answer is to change the parsetree representation, or to try to make node print/read smarter about this looping structure. But I'd incline to the first --- the looped structure puts all sorts of tree-traversal algorithms at risk. regards, tom lane
В списке pgsql-hackers по дате отправления: