Re: [BUGS] Bug in the information_schema.referential_constraints view

2003-10-16 Thread Tom Lane
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane writes: >> No, because that would entail a genuine loss of capability: FK >> constraints couldn't be built using indexes that were made by CREATE >> UNIQUE INDEX rather than through the unique/pk constraint syntax. >> In particular this would

Re: [BUGS] Bug in the information_schema.referential_constraints

2003-10-16 Thread Peter Eisentraut
I have fixed the problem with the keys being in different order and the problem of missing unique constraints. Tom Lane writes: > >> Which there may not be (the backend code for creating an FK checks for a > >> matching unique index, quite a different animal). > > > I think that should be changed

Re: [BUGS] Bug in the information_schema.referential_constraints view

2003-10-16 Thread Tom Lane
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane writes: >> Another problem is that the view will fail to list FK constraints at all >> if it cannot identify a matching unique constraint. > If you want information under those conditions, you're looking at the > wrong view. table_constraint

Re: [BUGS] Bug in the information_schema.referential_constraints

2003-10-16 Thread Peter Eisentraut
Tom Lane writes: > > AND con.contype = 'f' > > AND con.confrelid = pkc.conrelid > > I think this is correct as far as it goes, but there are more problems. Added. > For one, I believe we also need to check the contype of the pkc row; > otherwise matches against check constrai

Re: [BUGS]

2003-10-16 Thread Tom Lane
Igor Shevchenko <[EMAIL PROTECTED]> writes: > On Tuesday 14 October 2003 20:50, you wrote: >> I think we're going to need a test case to make any progress on this >> one. > Here's a test case. Thanks. Turns out to have been an interaction between NOTIFY and the new V3 query protocol. Fix commit

Re: [BUGS]

2003-10-16 Thread Igor Shevchenko
On Tuesday 14 October 2003 20:50, you wrote: > Igor Shevchenko <[EMAIL PROTECTED]> writes: > > The problem is repeatable when I run my program, especially if the > > postgresql server and the sserv are on the same server, and the debugging > > is off. Please let me know if you need more details, I'

Re: [BUGS] timestamp bug 7.4beta3

2003-10-16 Thread Nayib Kiuhan
> It's not like it's hard to fix post-upgrade (or pre-upgrade, for that > matter): a simple "ALTER TABLE ... SET DEFAULT now()" will do it. Like 'now' and now() are both valid, at least will be good to have a note when a table that includes 'now' is created, bringing the attention to people to

Re: [BUGS] timestamp bug 7.4beta3

2003-10-16 Thread Nayib Kiuhan
Thank you for your answer. I tried before with 'now()' (inside the single aspen) and didn't work . Now it is working very well without the aspens as you already mentioned. It is a good idea to through out an error during the table creation if the format is not as indicated (now()), because when