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
EVERYTIME 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
yourtable, 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
notharm.
--
Fabien Coelho - coelho@cri.ensmp.fr
