I don't think I am crazy and the user who showed me the problem exists - but
damn it neither he or I cannot duplicate the problem. The only thing that
changed is each of us has logged out of our session and logged back in.
The only thing that could have happened is that sometime in the past the
schema search path changed after the user logged in. There was no other table
with a duplicate name in another schema.
Thanks for doing the sanity check.
Joel
Tom Lane wrote:
> Joel Krajden <joelk@cs.concordia.ca> writes:
>
>>But if I create the tables as a mortal user or create them as postgres
>>but in the schema of user joelk and grant all to user joelk, I can
>>insert data without the foreign key constraint being respected. Now if
>>I drop the foreign key constraint and recreate it with a schema prefix
>>in the references section, the constarint works fine.
>
>
> This is even harder to believe than the first report. Could we see a
> complete, self-contained test case? A SQL script that demonstrates the
> problem from a standing start in an empty database is what I have in mind.
>
> (What I suspect is that you have multiple similarly-named tables in
> different schemas and are getting confused by that...)
>
> regards, tom lane
--
| Joel Krajden | Rm: LB-915, Tel: 514 848-2424 3052 |
| | Fax: 514 848-2830 |
| Senior Systems Analyst | Email: joelk@cs.concordia.ca |
| Engineering & Computer Sc.| http://www.cs.concordia.ca/~staffcs/joelk |
| Concordia University | Remember it's a circus and the clowns |
| Montreal, Canada | are supposed to make you laugh, not cry. |
