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)
Список
Дерево обсуждения
[NOT] (LIKE|ILIKE) (ANY|ALL) (...) Fabien COELHO <coelho@cri.ensmp.fr>
Re: [NOT] (LIKE|ILIKE) (ANY|ALL) (...) Tom Lane <tgl@sss.pgh.pa.us>
Re: [NOT] (LIKE|ILIKE) (ANY|ALL) (...) Fabien COELHO <coelho@cri.ensmp.fr>
Re: [NOT] (LIKE|ILIKE) (ANY|ALL) (...) Tom Lane <tgl@sss.pgh.pa.us>
Re: [NOT] (LIKE|ILIKE) (ANY|ALL) (...) Fabien COELHO <coelho@cri.ensmp.fr>
Fabien COELHO 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 по дате отправления