From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org, CG <cgg007(at)yahoo(dot)com>, Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
Subject: | Re: Foreign keys for non-default datatypes |
Date: | 2006-02-24 01:58:16 |
Message-ID: | 43FE6838.4070105@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2006-02-24 02:43:39 | Re: fsutil ideas |
Previous Message | Michael Glaesemann | 2006-02-24 01:56:52 | Re: suggestion |