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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
