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 по дате отправления:

Предыдущее
От: Thomas Lockhart
Дата:
Сообщение: Re: [HACKERS] ISO dates with European Format
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Patch for user-defined C-language functions