Re: [HACKERS] serial type

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Patch for user-defined C-language functions
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Status report: long-query-string changes