Re: [PATCHES] Foreign key type checking patch - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [PATCHES] Foreign key type checking patch
Date
Msg-id Pine.LNX.4.58.0403021801191.28778@sablons.cri.ensmp.fr
Whole thread Raw
In response to Re: [PATCHES] Foreign key type checking patch  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Bruno Wolff III
Date:
Subject: Re: Check Constraints and pg_dump
Next
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] select statement against pg_stats returns