Crash on userdefined operator

Started by Mario Weilguniover 25 years ago2 messages
#1Mario Weilguni
mweilguni@sime.com

-----BEGIN PGP SIGNED MESSAGE-----

Sorry to bother you with this question, but I've found a bug with operators:
Example:

create table dummy ( a numeric(12,0), b float8);
insert into dummy (a,b) values (1, 2);
insert into dummy (a,b) values (7, 7);
insert into dummy (a,b) values (3, 2);
insert into dummy (a,b) values (4, 2);

Now try:
select * from dummy where a=b;
ERROR: Unable to identify an operator '=' for types 'numeric' and 'float8'
You will have to retype this query using an explicit cast

So I tried to define an operator:
create function num_eq_float (numeric, float8) returns bool as
'select $1::float8 = $2::float8' language 'sql';

select * from dummy where num_eq_float(a,b)=true;
a | b
- ---+---
7 | 7
(1 row)

Works fine so far. Now I tried:
create operator = (
leftarg = numeric,
rightarg=float8,
procedure = num_eq_float
);
CREATE

And now I tried:
select * from dummy where a=b;
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

Obviously the backend process crashed, but I have no clue what I might be
doing wrong.

Regards,
Mario Weilguni

- --
Why is it always Segmentation's fault?
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBObU8xwotfkegMgnVAQGuqAP/TFk6HYqVmKdmv5WqRiIlChYQbGNWnEDv
BYG183EXfeYoPkCZXU2ZJVbYUZObHVssxrFNEmoXgOdVJ1BLaVoVwIA3UFjAkZ4f
mPaS7kSSWYDf1EvGPMCiFc9TYdLDI0M1GsBUKNjeLEqwlAdXWiVEjrSLBgnMZXa+
+e+3vMSv4Fc=
=ok3E
-----END PGP SIGNATURE-----

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Mario Weilguni (#1)
Re: Crash on userdefined operator

Mario Weilguni <mweilguni@sime.com> writes:

Sorry to bother you with this question, but I've found a bug with operators:

Operators backed by SQL-language functions aren't supported in 7.0 (nor
any previous version). You should be able to do this in plpgsql though.

This restriction is fixed for 7.1 btw...

regards, tom lane