Re: Help with casting and comparing. - Mailing list pgsql-hackers

I looked around in the code and the whole thing looks complex
and prone to breaking my code often, i.e., whenever someone will decide to
change the casting/operators. I thought about just
issuing in SPI_prepare query the proper casting like:
SELECT a0::text,a1::text ...
Casting to equal types (when neccessary) will allow me to just
use regular equality functions.
And perhaps the added benefit is that the casted values are cached? since
i restart cursor scans often(by moving to start not reopening).
The downside is that i noticed that the CTID is removed from the tuple
if a cast occurs. Is there a way to tell postgresql to not remove the
CTID?
The other way, of course is to add CTID as an attribute in the query
but it seems less efficient since i am accessing it repeatedly.


On Wednesday 28 June 2006 18:12, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.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
> http://archives.postgresql.org/pgsql-hackers/2006-02/msg00960.php
> 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

--
Regards,
��������Tzahi.
--
Tzahi Fadida
Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
WARNING TO SPAMMERS: �see at
http://members.lycos.co.uk/my2nis/spamwarning.html