Re: Re: BUG #4078: ERROR: operator does not exist: numeric = character varying

From: Eric Haszlakiewicz <erh(at)swapsimple(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Re: BUG #4078: ERROR: operator does not exist: numeric = character varying
Date: 2008-10-14 15:49:47
Message-ID: 20081014154947.GA24588@poe.swapsimple.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-general

On Mon, Oct 13, 2008 at 09:10:41PM -0400, Tom Lane wrote:
> Eric Haszlakiewicz <erh(at)swapsimple(dot)com> writes:
> > I created this, which seems to solve the problem:
>
> > create function casting_eq_operator(integer, "char")
> > returns boolean as 'begin
> > return $1 = cast ($2 as integer);
> > end;' language plpgsql immutable strict;
>
> > CREATE OPERATOR = (PROCEDURE = casting_eq_operator,
> > LEFTARG = integer , RIGHTARG = "char",
> > COMMUTATOR = =, NEGATOR = !=, HASHES, MERGES
> > );
>
> > Can this be included by default?
>
> No. Even if we desired to reverse the decision about not having
> implicit casting behavior, this definition of the operator would not be
> appropriate because it provides the opposite of the old behavior.
> The pre-8.3 behavior would have been to cast the integer to text and
> apply a textual comparison; which gives different comparison behavior,
> eg leading zeroes in the string would affect the result. Not to mention
> that the cast to integer in this definition would fail outright if the
> string didn't look like an integer.
>
> A large part of the reasoning for getting rid of the implicit casts
> was exactly that it's not very clear what a comparison of this sort
> should act like, and most people who are accidentally invoking it
> haven't thought that through either.

hmm.. I was thinking that a comparison between a number and a string
would cause an error if the string wasn't parseable. Now that I
think about it more, I can see that having it just return false might
be reasonable too.

>
> (Some other problems: I'm pretty sure you meant to refer to text or
> varchar not "char"; you referenced commutator and negator operators
> without defining them; this operator certainly does not hash, and
> I don't think it merges either, though maybe you could make the latter
> work if you'd provided all the requisite btree-opfamily infrastructure.)

Yeah, you're right. I didn't think that through entirely.
Sorry for the noise.

eric

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tony Marston 2008-10-14 23:54:16 Re: BUG #4465: GROUP BY is not to SQL standard
Previous Message Robert 'BoBsoN' Partyka 2008-10-14 14:10:38 BUG #4478: = operator in connection with CASE looks like loose some functionality (bug or feature?)

Browse pgsql-general by date

  From Date Subject
Next Message Bill Thoen 2008-10-14 16:04:39 Update with a Repeating Sequence
Previous Message Andrus 2008-10-14 15:43:30 How to get schema name which violates fk constraint