Re: [PATCHES] Foreign key type checking patch
Dear Tom, Thanks for your reply. Here is a proposed patch against 7.4.1 to check exact match of foreign key types wrt the referenced keys, and to show a warning if this is not the case. I think that this concern may be obsolete in CVS tip, I just get the current CVS and had a quick look at it. at least for the cases where we have indexable cross-type operators. The correct way to do this would be to look at the operator found by oper() and see whether it's indexable. I must admit that I do not understand your point. I wish I would have a WARNING if a foreign key is not declared exactly as the key it references. I think that it is a desirable feature for stupid users, including myself! I cannot see why whether the = comparison version which is chosen is indexable or not would lead to this information. It seems quite reasonnable to look directly at the attribute types and compare them for this purpose. I noticed the compatible_oper() function which would return a no-coersion binary operator between types. However that does not fit my purpose. For instance, it seems to me that the IsBinaryCoercible returns true for VARCHAR(12) and VARCHAR(16), as the type oid is the same, but I think a warning makes sense anyway. So it is not the same issue. So I can't see your point. Maybe some more lights would help? -- Fabien. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] Foreign key type checking patch
Hello again patchers, Here is a proposed patch against 7.4.1 to check exact match of foreign key types wrt the referenced keys, and to show a warning if this is not the case. This is an attempt to prevent stupid bugs such as : CREATE TABLE foo(id INT4 NOT NULL PRIMARY KEY); CREATE TABLE bla(id INT2 REFERENCES foo); which may work at the beginning, and then fails later on. I'm not at ease with postgresql internals, however this implementation seems reasonnable to me, and in the spirit of how the surrounding code works. I could not find any simple way to tell the user about what is being processed, as there is not real context information and tell 'while processing this constraint'... However this situation seems to be the normal case with any postgresql messages, as far as I can tell from my use. Have a nice day, -- Fabien Coelho - [EMAIL PROTECTED] fk_type_check.diff.gz Description: Binary data ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Foreign key type checking patch
Fabien COELHO [EMAIL PROTECTED] writes: Here is a proposed patch against 7.4.1 to check exact match of foreign key types wrt the referenced keys, and to show a warning if this is not the case. I think that this concern may be obsolete in CVS tip, at least for the cases where we have indexable cross-type operators. The correct way to do this would be to look at the operator found by oper() and see whether it's indexable. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Foreign key type checking patch
Stephan Szabo [EMAIL PROTECTED] writes: I'm really not sure that it makes sense to warn for the fk cases where the semantics should be correct (if they're not we need to fix it or make it an error) but in which an error might have been made by the user because the types are different given that it at least seems reasonable to me that the fk type is allowable to be a subset of the referenced type. I don't think simply different types is sufficient to be warning material. I can think of several cases where it might be reasonable for the types to be different. One case in particular that needs some thought is where the FK and referenced PK are domains on a common base type. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Foreign key type checking patch
I can think of several cases where it might be reasonable for the types to be different. Sure. It's all about a warning, not about an error. -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
