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

Re: Help with casting and comparing.

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

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

Note that this still leaves the question of what operator to search for,
and where to look for it.  The current system doesn't really provide an
adequate way of identifying a suitable equality operator; you kind of
have to take it on faith that people won't have made "=" do unexpected
things (an assumption already violated by some builtin datatypes ...).
We've been moving gradually in the direction of relying on btree
operator classes to give us a better understanding of which operators
really act like equality, but it's far from all done.

The most recent thread about fixing this was
Nothing much has been done since then as far as fixing foreign-key
checks, but you might want to look at the code for interpreting row
value comparisons (make_row_comparison_op in parse_expr.c).
SelectSortFunction in tuplesort.c is another example of looking for
btree info to infer the behavior of an operator.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Phil FrostDate: 2006-06-28 15:24:25
Subject: Re: optimizing constant quals within outer joins
Previous:From: Martijn van OosterhoutDate: 2006-06-28 15:11:59
Subject: Re: optimizing constant quals within outer joins

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