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
|
Список | 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 по дате отправления: