Re: Designing an extension for feature-space similarity search

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Designing an extension for feature-space similarity search
Дата
Msg-id 2697.1329435735@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Designing an extension for feature-space similarity search  (Jay Levitt <jay.levitt@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Qual evaluation cost estimates for GIN indexes
Следующее
От: Dan Scales
Дата:
Сообщение: Re: possible new option for wal_sync_method