Re: [NOT] (LIKE|ILIKE) (ANY|ALL) (...)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [NOT] (LIKE|ILIKE) (ANY|ALL) (...)
Дата
Msg-id 23575.1080312717@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [NOT] (LIKE|ILIKE) (ANY|ALL) (...)  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: [NOT] (LIKE|ILIKE) (ANY|ALL) (...)  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-patches
Fabien COELHO <coelho@cri.ensmp.fr> writes:
>> This seems to allow a whole lot of unintended and probably uncool things
>> as well.  "ORDER BY NOT LIKE", for instance.

> Well, it seemed to me (maybe I'm wrong here/) that "ORDER BY !~~" was
> allowed anyway by the parser, so I cannot see why it should not allow "NOT
> LIKE" as well, even if it does not make sense.

Possibly.  The case that I thought was a real bad idea was actually the
one in def_arg --- we don't want that doing any behind-the-scenes
translation of words to other things.  The ORDER BY case is just silly.

> Or the rule factorization must be changed. It can also be done.

Yes.  I think we must have an all_subselect_ops or similar.

            regards, tom lane

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

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: [NOT] (LIKE|ILIKE) (ANY|ALL) (...)
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Two-phase commit