Re: Designing an extension for feature-space similarity search - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Designing an extension for feature-space similarity search
Date
Msg-id 2697.1329435735@sss.pgh.pa.us
Whole thread Raw
In response to Re: Designing an extension for feature-space similarity search  (Jay Levitt <jay.levitt@gmail.com>)
List pgsql-hackers
Jay Levitt <jay.levitt@gmail.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Qual evaluation cost estimates for GIN indexes
Next
From: Dan Scales
Date:
Subject: Re: possible new option for wal_sync_method