On Jun19, 2011, at 22:10 , Tom Lane wrote: > Andrew Dunstan <and...@dunslane.net> writes: >> On 06/19/2011 02:56 PM, Robert Haas wrote: >>> On Sun, Jun 19, 2011 at 9:53 AM, Florian Pflug<f...@phlo.org> wrote: >>>> Amidst the discussion, Alvaro suggested that we resolve the issue >>>> by adding a distinct type for patterns as opposed to text. That'd >>>> allow us to make "~" it's own commutator by defining both >>>> text ~ pattern >>>> and >>>> pattern ~ text. > >>> That's kind of a neat idea. There might be an efficiency benefit to >>> having a regex type that is precompiled by the input function. > >> What do we do when we get text or unknown in place of pattern? How are >> we going to know if the pattern is supposed to be the left or right operand? > > Yeah, this would result in > SELECT 'something' ~ 'something'; > failing outright. I don't think it's a good substitute for biting > the bullet and choosing distinct operator names.
Yeah, well, the complaint (put forward mainly by Alvaro) that lead to this approach in the first place was precisely that 'something' ~ 'anything' *doesn't* give any indication of what constitutes the pattern and what the text. So I consider that to be a feature, not a bug. BTW, arithmetical operators currently show exactly the same behaviour postgres# select '1' + '1' ERROR: operator is not unique: unknown + unknown at character 12 The only argument against that I can see is that it poses a compatibility problem if "~" remains the pattern matching operator. I do believe, however, that the chance of unknown ~ unknown appearing in actual applications is rather small - that'd only happen if people used postgresql's regexp engine together with purely external data. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
