X-Original-To: pgsql-bugs-postgresql.org@localhost.postgresql.org
Received: from localhost (neptune.hub.org [200.46.204.2])
	by svr1.postgresql.org (Postfix) with ESMTP id 371DFD1B910
	for <pgsql-bugs-postgresql.org@localhost.postgresql.org>;
	Sun, 23 Nov 2003 18:44:22 +0000 (GMT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024)
	with ESMTP id 65556-09
	for <pgsql-bugs-postgresql.org@localhost.postgresql.org>;
	Sun, 23 Nov 2003 14:43:51 -0400 (AST)
Received: from sss.pgh.pa.us (unknown [192.204.191.242])
	by svr1.postgresql.org (Postfix) with ESMTP id C3C13D1D5C8
	for <pgsql-bugs@postgresql.org>; Sun, 23 Nov 2003 14:43:49 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.12.10/8.12.10) with ESMTP id hANIhn19028504;
	Sun, 23 Nov 2003 13:43:49 -0500 (EST)
To: "Douglas M. Westfall" <dougw@net.kent.edu>
Cc: pgsql-bugs@postgresql.org
Subject: Re: Bug Report 
In-reply-to: <1069387744.2491.1.camel@dw2> 
References: <1069387744.2491.1.camel@dw2>
Comments: In-reply-to "Douglas M. Westfall" <dougw@net.kent.edu>
	message dated "Thu, 20 Nov 2003 23:09:04 -0500"
Date: Sun, 23 Nov 2003 13:43:49 -0500
Message-ID: <28503.1069613029@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Archive-Number: 200311/171
X-Sequence-Number: 7214

"Douglas M. Westfall" <dougw@net.kent.edu> writes:
> 1) table contains a valid inet field
> 2) query works fine in pgsql 7.2 & 7.3
> 3) query no longer works in pgsql 7.4

> select * from <table> where <field> ilike '%<inetvalue>%' ;  
> ERROR:  Unable to identify an operator '~~*' for types 'inet' and '"unknown"'
>         You will have to retype this query using an explicit cast

This certainly did not work in 7.3 (in fact, you are quoting the 7.3
spelling of the error message).

There is not and never has been a LIKE operator for inet values; it's
only defined for textual data types.  The reason it "worked" in 7.2 was
that 7.2 would implicitly cast the inet value to text for you.  In 7.3
we changed a lot of casts to not be implicitly invocable, because of the
potential for unexpected behavior.  Personally I'd class this as an
example of exactly the kind of unexpected behavior we meant to
prevent...

Short anser: cast the field value to text.

			regards, tom lane