Re: Designing an extension for feature-space similarity search

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jay Levitt <jay(dot)levitt(at)gmail(dot)com>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Designing an extension for feature-space similarity search
Date: 2012-02-16 23:42:15
Message-ID: 2697.1329435735@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jay Levitt <jay(dot)levitt(at)gmail(dot)com> writes:
> Tom Lane wrote:
>>> - Can domains have operators, or are operators defined on types?
>>
>> I think the current state of play is that you can have such things but
>> the system will only consider them for exact type matches, so you might
>> need more explicit casts than you ordinarily would.

> Turns out it's even smarter than that; it seems to coerce when it's unambiguous:

Yeah, that sort of case will probably work all right. The thing to keep
in mind is that operators/functions declared to take domains are
definitely second-class citizens, and will lose out in many
somewhat-ambiguous cases where an operator on a base type could get
selected due to the ambiguity resolution rules. For your application it
will probably help if you can pick an operator name that's not in use
for any operation on the base type(s). Also, it's conceivable that it
won't matter much to you, since I gather these operators will mostly get
invoked "behind the scenes" and not directly written in queries; it
should not be too hard to avoid ambiguity in mechanically-generated
references.

(There was a good deal of chatter some years ago about trying to improve
support of functions taking domains, but nothing's gotten done yet.)

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dan Scales 2012-02-17 00:17:27 Re: possible new option for wal_sync_method
Previous Message Tom Lane 2012-02-16 23:30:53 Re: Qual evaluation cost estimates for GIN indexes