Re: Foreign keys for non-default datatypes

Поиск
Список
Период
Сортировка
От Christopher Kings-Lynne
Тема Re: Foreign keys for non-default datatypes
Дата
Msg-id 43FE6838.4070105@familyhealth.com.au
обсуждение исходный текст
Ответ на Re: Foreign keys for non-default datatypes  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Foreign keys for non-default datatypes  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> No, there's no need for that.  It means that the RI stuff would have to
> take whatever steps we agree on to determine the exact comparison
> operator to use, and then be sure to emit SQL that will select exactly
> that operator --- this involves using the OPERATOR(foo.=) syntax to
> remove schema-ambiguity and possibly adding explicit type coercions of
> the operands.  This'll make the RI queries noticeably uglier, but
> they're not meant to be read by humans anyway.  I think it wouldn't be
> any slower, because OPERATOR() syntax will suppress a search-path
> search that the parser would otherwise make for the operator --- but
> in any case, since the plan result is cached, a few microseconds here or
> there won't matter.

Incidentally, shouldn't the existing RI queries (eg. SELECT ... FOR 
SHARE) explicity specify operator(pg_catalog.=)?  Or are they safe from 
that for some other reason?

Chris



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: suggestion
Следующее
От: Michael Glaesemann
Дата:
Сообщение: Re: suggestion