From: | "Rod Taylor" <rbt(at)zort(dot)ca> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Hackers List" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Regression tests and NOTICE statements |
Date: | 2002-05-09 12:35:08 |
Message-ID: | 292c01c1f755$f45a3d40$ad02000a@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> "Rod Taylor" <rbt(at)zort(dot)ca> writes:
> > installcheck will continue to fail if not run immediatly after an
> > initdb however.
>
> Not acceptable. Quite aside from it not being okay to force an
initdb
> to do a regression test, any tiny change to any part of the regress
> tests will probably alter OID assignments in later tests.
The above is the reason I proposed turning off NOTICE statements.
>From what I can see 99% of them aren't useful. The tests confirm the
information that NOTICE gives off in better ways anyway. With them
off, the sudo-random names simply aren't shown anywhere. Only the
effects of the constraints (of any type) are seen.
> Why are you inserting OIDs into constraint names anyway? I thought
> we had just agreed that the RI trigger naming arrangement was a bad
idea
> and we should change it.
Oh. I didn't know it was a bad idea (aside from being a little OID
wasteful).
Ok, I need something guarenteed unique, system generated, and I really
didn't like the way CHECK constraints test a name, increment a
counter, test the new name, increment a counter, test yet another
name, increament a counter, .....
So.. Is there a good way to do this? Or was the above CHECK
constraint method of testing ~10 different names with each creation
good enough.
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2002-05-09 13:05:53 | Fw: Regression tests and NOTICE statements |
Previous Message | Marc G. Fournier | 2002-05-09 11:51:19 | Re: Path to PostgreSQL portabiliy |