Dear Stephan, > > Although it is POSSIBLE that this is fine, it is much more PROBABLE that > > it is a bug, hence I just suggest to issue a mere simple basic plain > > user-friendly little warning, what is quite different from issuing an > > error. [...] Why not allowing that kind of approach in postgres? > > Because producing noise warnings often *lower* the amount of use you get > from real warnings.
Ok, I understand this argument. I agree with the general idea... However I think that this case is special enough in the sense that: (1) it should occur rarely, and when it occurs (2) it should be most of the time appropriate. > If one has to wade through useless messages to divine the ones that are > meaningful, overall many people just start ignoring all warnings. I > could be convinced that it is "notice" material, since people who don't > want to see it probably don't want to see the other notices either, but > warning seems way to strong to me. Well, I used "NOTICE" in my suggested implementation, so it is fine;-) > Fundamentally, I don't see a huge difference between this and > select * from foo,bla where foo.fid=bla.fid; > where the same general constraints on meaningful values apply. 1/ The warning I'm suggesting is ONCE in the life-time of the table, when it is declared. Your above case would be EVERY TIME a join is issued on the tables, which is likely to be quite often! 2/ If you use a select with a join, and if your modelisation is correct, then you must have declared a foreign key on your table, so you already get the warning at that time. If you chose to ignore it, you must be right! 3/ If you bother to declare foreign keys, you want them to be sound, so if postgres can help a little bit, that should not harm. -- Fabien Coelho - [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org