Re: Foreign keys for non-default datatypes
От | Stephan Szabo |
---|---|
Тема | Re: Foreign keys for non-default datatypes |
Дата | |
Msg-id | 20060223114052.Q8064@megazone.bigpanda.com обсуждение исходный текст |
Ответ на | 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 |
On Thu, 23 Feb 2006, Tom Lane wrote: > I looked into the problem reported here: > http://archives.postgresql.org/pgsql-admin/2006-02/msg00261.php > To wit, a pg_restore of a foreign key constraint involving user-defined > types produces > > pg_restore: WARNING: foreign key constraint "luuid_fkey" will require costly sequential scans > DETAIL: Key columns "luuid" and "luuid" are of different types: public.uniqueidentifier and public.uniqueidentifier. > > A small variation of the example (I tried it with the contrib isbn type > instead, just to see if it was uniqueidentifier's fault) produces > complete failure: > > isbn=# ALTER TABLE ONLY beta ADD CONSTRAINT beta_luuid_fkey FOREIGN KEY (luuid) REFERENCES alpha(luuid); > ERROR: foreign key constraint "beta_luuid_fkey" cannot be implemented > DETAIL: Key columns "luuid" and "luuid" are of incompatible types: public.isbn and public.isbn. > > The problem is that pg_dump likes to set a restrictive search path: > the above follows > isbn# SET search_path = delta, pg_catalog; > while the data type and its operators all are defined in the public > schema. So when ATAddForeignKeyConstraint checks to see if there's a > suitable "=" operator, it doesn't find the intended operator. In the > isbn case it doesn't find anything at all; in the uniqueidentifier case > there's an implicit cast to text and so the texteq operator is found, > but it's not a member of the index's opclass and thus the warning > appears. > > Even if ATAddForeignKeyConstraint weren't trying to be helpful by > checking the operator, we'd be facing the exact same risks at runtime > --- the RI triggers blithely assume that "foo = bar" will do the right > thing. > > This has been a hazard in the RI code since day one, of course, but > I think it's time to face up to it and do something about it. The > RI code ought not be assuming that "=" will find an appropriate > operator --- it should be doing something based on semantics, not a > pure name search, and definitely not a search-path-dependent search. > > This ties into Stephan's nearby concerns about whether unique indexes > using nondefault opclasses make sense as infrastructure for foreign > key checks. The answer of course is that they make sense if and only > if the "=" operator used for the RI check is a member of the index > opclass. Right, when I'd said "or we allow you to specify a different equality operator for that case which matches the one in the opclass" I sort of was thinking that direction, although I was considering either matching the index one or allowing you to specify the operator if we went that way. Those still bug me a little (especially matching the index one) because writing out the constraint's check by hand by looking at the spec would give different results. > Any thoughts about details? My feeling is that we should tie RI > semantics to btree opclasses, same as we have done for ORDER BY > and some other SQL constructs, but I don't have a concrete proposal > right offhand. The btree idea may not cover cross-type FKs anyway. ISTM that the btree opclass is too restrictive right now since I'm guessing we'd want to allow say int4 <-> numeric which I don't think is in either btree opclass, but I don't know if they're not there because it wasn't worth putting in or if there's a more fundamental reason.
В списке pgsql-hackers по дате отправления: