Re: [HACKERS] Check Constraints and pg_dump

2004-03-02 Thread Robert Treat
On Monday 01 March 2004 22:59, Curt Sampson wrote: On Mon, 1 Mar 2004, Tom Lane wrote: Curt Sampson [EMAIL PROTECTED] writes: Can you explain how to do this? There is no reference to a plan in the contract table; the constraint just checks to see that, if a contract exists, there is at

Re: [HACKERS] Check Constraints and pg_dump

2004-03-02 Thread Bruno Wolff III
On Tue, Mar 02, 2004 at 09:45:03 -0500, Robert Treat [EMAIL PROTECTED] wrote: Wouldn't a FK on both tables be the appropriate schema? With the FK on contract being deffered? No, since he only cares that there is at least one plan for a contract, not a particular plan. You can do something

Re: [HACKERS] Check Constraints and pg_dump

2004-03-02 Thread Curt Sampson
On Tue, 2 Mar 2004, Robert Treat wrote: Wouldn't a FK on both tables be the appropriate schema? With the FK on contract being deffered? Unfortunately, it appears that an FK must reference a unique column. So this: ALTER TABLE contract ADD CONSTRAINT contract_must_have_a_plan

Re: [HACKERS] Check Constraints and pg_dump

2004-03-01 Thread Curt Sampson
On Thu, 26 Feb 2004, Tom Lane wrote: Jonathan Scott [EMAIL PROTECTED] writes: The functions and tables create just fine, but when it gets to the COPY part of the sql script, it tries to load tables in what really is the wrong order. The check constraint is making sure there is a plan

Re: [HACKERS] Check Constraints and pg_dump

2004-03-01 Thread Tom Lane
Curt Sampson [EMAIL PROTECTED] writes: Can you explain how to do this? There is no reference to a plan in the contract table; the constraint just checks to see that, if a contract exists, there is at least one plan referencing that contract. There is of course a foreign key constraint used in

Re: [HACKERS] Check Constraints and pg_dump

2004-03-01 Thread Curt Sampson
On Mon, 1 Mar 2004, Tom Lane wrote: Curt Sampson [EMAIL PROTECTED] writes: Can you explain how to do this? There is no reference to a plan in the contract table; the constraint just checks to see that, if a contract exists, there is at least one plan referencing that contract. There is

Re: [HACKERS] Check Constraints and pg_dump

2004-02-29 Thread Jonathan Scott
Tom, I have another instance of a possible function being used as a check constraint: a function that makes sure there is one row, and only one row in a table. At table creation, and the creation of the constraint, there are no rows in the table. So, even if the constraint is a valid one to

Re: [HACKERS] Check Constraints and pg_dump

2004-02-26 Thread Tom Lane
Jonathan Scott [EMAIL PROTECTED] writes: The functions and tables create just fine, but when it gets to the COPY part of the sql script, it tries to load tables in what really is the wrong order. The check constraint is making sure there is a plan before there is a contract, yet pg_dump is

[HACKERS] Check Constraints and pg_dump

2004-02-25 Thread Jonathan Scott
Hello again, A project I am working on has been having problems with pg_dump's output, using 7.3. Our project's database includes functions that do constraint checking for us, as well as circular dependencies. We heard about the changes on the pgsql HEAD/7.5, and have given it a try. It fixed

Re: [HACKERS] CHECK constraints in pg_dump

2003-02-26 Thread Tom Lane
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Why would there be any speed advantage? Is it not faster to add it when all the data is there, rather than evaluating it as each row is inserted, like indexes? I don't see why. There are good algorithmic reasons why bulk-loading an index is

[HACKERS] CHECK constraints in pg_dump

2003-02-25 Thread Christopher Kings-Lynne
Hi guys, I notice that we're still dumping CHECK constraints as part of the CREATE TABLE statement, and not as an ALTER TABLE statement after the data has been loaded. Should we move it to after the data for speed purposes, like we have with all other constraints? Chris

Re: [HACKERS] CHECK constraints in pg_dump

2003-02-25 Thread Christopher Kings-Lynne
Christopher Kings-Lynne [EMAIL PROTECTED] writes: I notice that we're still dumping CHECK constraints as part of the CREATE TABLE statement, and not as an ALTER TABLE statement after the data has been loaded. Should we move it to after the data for speed purposes, like we have with