Re: operator exclusion constraints

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: operator exclusion constraints
Дата
Msg-id 6379.1257185577@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: operator exclusion constraints  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: operator exclusion constraints
Список pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> On Mon, 2009-11-02 at 08:25 +0000, Peter Eisentraut wrote:
>> I think the word CHECK should be avoided completely in this syntax, to
>> avoid confusion with CHECK constraints.

> This is an easy change. I don't have a strong opinion, so the only thing
> I can think to do is ask for a vote.

> Do you have a specific alternative in mind? How about just "WITH"?

I think we had that discussion already, and rejected using "WITH" by
itself because it was so totally devoid of suggestion of what it was
the system would do "with" the expression or operator.

If we don't want to introduce a new reserved word it's difficult to
find alternatives :-(.  One thing that just came to mind is that we
might be able to do something like
EXCLUSION (expr CHECK NOT operator)
orEXCLUSION (expr CONSTRAIN NOT operator)

I like the "NOT" here because "CHECK NOT =" seems to convey pretty
clearly what it is you are checking for.  Because NOT is reserved and
can't appear as a connective, I think that this approach might allow
a non-reserved leading word, thus possibly the second variant would
work without reserving CONSTRAIN.  I have not tested whether bison
agrees with me though ;-).  In any case I think "CHECK NOT =" reads
pretty well, and don't feel a strong urge to use some other word there.
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Renaming conversion procs (was Re: [GENERAL] Error on compile for Windows)
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Architecture of walreceiver (Streaming Replication)