|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Brian Hurt <bhurt(at)janestcapital(dot)com>|
|Subject:||Re: Generic hash function?|
|Views:||Raw Message | Whole Thread | Download mbox|
Brian Hurt <bhurt(at)janestcapital(dot)com> writes:
> Tom Lane wrote:
>> What for?
> What I'd like to write is [ x=y meaning x IS NOT DISTINCT FROM y ]
> Am I going to need to create an operator class for every type?
If you want it to be indexable you're going to have to do a lot more
work than that. btree generally assumes that the comparison functions
are strict, and the other index AMs discriminate against nulls even
more strongly, eg, hash doesn't store nulls at all. I think the hash
and merge join code is designed to ignore nulls as well.
On the whole you'd likely find it a lot simpler to reconsider the ways
your application is using NULL. Assuming that NULL = NULL is
fundamentally against the SQL spec, and you will be forever swimming
upstream if you try to make PG handle it that way.
regards, tom lane
|Next Message||Greg Quinn||2006-12-05 19:28:44||Default install options for silent install on Windows|
|Previous Message||Brian Hurt||2006-12-03 21:47:40||Re: Generic hash function?|