[NOT] (LIKE|ILIKE) (ANY|ALL) (...)
Dear Patchers,
Please find attached a patch which allows "LIKE/ILIKE/NOT LIKE/NOT ILIKE"
as operators for ANY/SOME/ALL constructs.
SELECT 'foo' LIKE ANY (ARRAY['%a','%o']);
It should also fix some other places where a "~~" operator was allowed,
but not the LIKE operator in the very same place.
However, this patch does not address "SIMILAR TO", as its "hacked"
implementation does not fit the already existing structures for ANY/ALL.
I've added a comment about this in the regression tests.
It validates for me against current CVS head.
Have a nice day,
--
Fabien Coelho.
Attachments:
like_any.patchtext/plain; charset=US-ASCII; name=like_any.patchDownload+78-0
Fabien COELHO <coelho@cri.ensmp.fr> writes:
Please find attached a patch which allows "LIKE/ILIKE/NOT LIKE/NOT ILIKE"
as operators for ANY/SOME/ALL constructs.
This seems to allow a whole lot of unintended and probably uncool things
as well. "ORDER BY NOT LIKE", for instance.
regards, tom lane
Fabien COELHO <coelho@cri.ensmp.fr> writes:
Please find attached a patch which allows "LIKE/ILIKE/NOT LIKE/NOT ILIKE"
as operators for ANY/SOME/ALL constructs.This seems to allow a whole lot of unintended and probably uncool things
as well. "ORDER BY NOT LIKE", for instance.
Yes.
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. I guess that it is filtered
out later anyway?
Or the rule factorization must be changed. It can also be done.
--
Fabien Coelho - coelho@cri.ensmp.fr
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
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.
Ok. So the current code is silly, but the patch must be sound;-)
Or the rule factorization must be changed. It can also be done.
Yes. I think we must have an all_subselect_ops or similar.
I'll do that and resubmit later.
--
Fabien Coelho - coelho@cri.ensmp.fr