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
> 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.
>
