Re: WIP: generalized index constraints

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: WIP: generalized index constraints
Дата
Msg-id 1250781846.21841.33.camel@jdavis
обсуждение исходный текст
Ответ на Re: WIP: generalized index constraints  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: WIP: generalized index constraints  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
On Thu, 2009-08-20 at 11:47 +0300, Heikki Linnakangas wrote:
> That sounds like the constraint is based on an existing index, but there
> can't be any existing indexes on a table that hasn't been created yet.
> If this creates the index, then the syntax needs to support specifying
> index access method and an opclass for all the columns.

Of course, thanks for pointing that out. To make it work at CREATE TABLE
time, the language would have to specify the index access method, and
the index name should be optional. Do you think it's worthwhile adjust
the syntax for that, or would it just bloat the CREATE TABLE syntax for
no reason?

I'm leaning toward not allowing it at CREATE TABLE time.

> It would be nice to have syntax to create the index and constraint in
> one command, so that the constraint can be checked while the index is
> being created. Otherwise you need an extra heap scan to check it.

I can leave the old syntax in:

CREATE INDEX <indexname> ON <tablename> USING <method> (a CONSTRAINT <op>, b CONSTRAINT <op>) ...;

and allow both.

However, I'm not sure if it's very easy to provide support for
concurrent index building. Should I block it, or is it worth
investigating further?

Regards,Jeff Davis



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ygor Degani
Дата:
Сообщение: Duplicated Keys in PITR
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Linux start script updates