Fw: Regression tests and NOTICE statements

I guess I answered my own question didn't I. The check constraint
method (test, then change, and test then change) is the only way to
guarentee uniqueness. Anything else could have interferance by the
user, or issues during a dump / restore where any numbered sequences
are reset.

--
Rod
----- Original Message -----
From: "Rod Taylor" <rbt@zort.ca>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Hackers List" <pgsql-hackers@postgresql.org>
Sent: Thursday, May 09, 2002 8:35 AM
Subject: Re: [HACKERS] Regression tests and NOTICE statements

"Rod Taylor" <rbt@zort.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

Show quoted text

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.