Skip site navigation (1) Skip section navigation (2)

Re: Help with casting and comparing.

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Tzahi Fadida <Tzahi(dot)ML(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Help with casting and comparing.
Date: 2006-06-28 14:44:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Jun 28, 2006 at 03:25:57PM +0300, Tzahi Fadida wrote:
> Hi,
> I need help finding out how to determine if two types are equality compatible
> and compare them.


> Currently i only allow two values only of the same type but i wish to allow
> to compare values like "20.2"=?20.2 or 20=?20.0 etc...
> The first step is to find out if two attributes are equality and casting 
> compatible, i.e., if one type can be cast to the other type so they can be 
> compared. Or, just equality compatible and the casting is done somehow behind
> the scene.

There's two ways an equality could work. For example, there are
equality operators that take parameters of different types. That's the
easy case. Then you have binary compatable types, and then types with
actual conversion functions.

Fortunatly the backend contains functions that do all this already.
Check out parser/parse_oper.c, in particular oper() and

You may have to be prepared to handle a parsetree to do the actual

/* oper() -- search for a binary operator
 * Given operator name, types of arg1 and arg2, return oper struct.
 * IMPORTANT: the returned operator (if any) is only promised to be
 * coercion-compatible with the input datatypes.  Do not use this if
 * you need an exact- or binary-compatible match; see compatible_oper.

Hope this helps,
Martijn van Oosterhout   <kleptog(at)svana(dot)org>
> From each according to his ability. To each according to his ability to litigate.

In response to


pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2006-06-28 15:11:59
Subject: Re: optimizing constant quals within outer joins
Previous:From: Tom LaneDate: 2006-06-28 14:42:43
Subject: Re: UUID's as primary keys

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group