s/UNSPECIFIED/SIMPLE/ in foreign key code?
От | Tom Lane |
---|---|
Тема | s/UNSPECIFIED/SIMPLE/ in foreign key code? |
Дата | |
Msg-id | 11331.1339882698@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: s/UNSPECIFIED/SIMPLE/ in foreign key code?
Re: s/UNSPECIFIED/SIMPLE/ in foreign key code? |
Список | pgsql-hackers |
Our foreign-key-related code uses MATCH_UNSPECIFIED to denote the default foreign key match behavior. This corresponds to the wording used in the SQL92 spec, for instance "If <match type> is not specified or if FULL is specified, ...". But I always found it rather confusing; it sounds like we don't know what match behavior we're supposed to implement. I notice that in SQL99 and later, the SQL committee introduced "MATCH SIMPLE" as a way to name the behavior that formerly had no name. So now they can write things like "If M specifies SIMPLE or FULL, ..." which seems much nicer to me. I think it would be a useful advance in readability if we replaced UNSPECIFIED by SIMPLE throughout the FK code, and barring objections I will go do that. A small flaw in this plan is that in pg_constraint.confmatchtype, MATCH_UNSPECIFIED is stored as 'u'. In a green field I'd just rename that to 's' for SIMPLE, but it seems possible that this would confuse client-side code such as pg_dump or psql. A quick look shows that neither of those programs actually look directly at pg_constraint.confmatchtype, instead relying on backend functions when they want to deconstruct a foreign key constraint. But there could well be other client code that would notice the change. So I'm a bit torn as to whether to change it and create a release-note-worthy compatibility issue, or to leave it as-is (with documentation notes that "u" for MATCH_SIMPLE is a historical accident). Thoughts? regards, tom lane
В списке pgsql-hackers по дате отправления: