> > I wish I would have a WARNING if a foreign key is not declared exactly as
> > the key it references.
>
> The reason why people want such a warning is that the RI checks tend to
> be slow if it's not the case. Accordingly, the warning should only
> appear if the check is actually going to be slow.
Ok. I understand this, and this is another issue.
> You sound like you think it's a bug that Postgres supports cross-type FK
> references at all.
I'm sorry I sound like that, because this is not what I really mean.
Maybe my poor English could stand some improvement so as to be able
to convey my thinking clearly to others.
> I disagree.
I totally agree with you.
This is not my point. I do not want to "disallow" cross-type foreign keys.
My point is just to *** WARN *** the stupid user (me) about potential
would-be bugs if the type does not match. A warning is not an error. It
just means "hey man, did you notice that? maybe that is not what you
meant, maybe it is what you meant...". Well, this is my idea of a warning.
Consider this example :
CREATE TABLE foo(fid VARCHAR(2) NOT NULL PRIMARY KEY);
CREATE TABLE bla(fid VARCHAR(4) REFERENCES foo);
Although the "fid" attribute is declared VARCHAR(4) in bla, you will
never be able to put more that a VARCHAR(2) value inside as it must
reference the foo table.
Now consider this other example :
CREATE TABLE foo(fid VARCHAR(2) NOT NULL PRIMARY KEY);
CREATE TABLE bla(fid VARCHAR(1) REFERENCES foo);
Some key of foo will never be able to be referenced by bla.
Maybe it is the intent of the user, maybe not.
Anyway, IMVHO, both these cases deserve a warning, even of there is no
actual cpu cost. Hence my patch proposal.
> It's a feature, albeit one whose implementation could stand improvement.
> The warning ought to come out in cases where people are going to be
> exposed to the implementation weaknesses.
I agree with the feature, I just wish there would be a warning.
The "implementation weaknesses" is another issue that I do understand
but that I did not try to address in the submitted patch.
--
Fabien.