Thread: Regression tests and NOTICE statements

I'm using OIDs for constraint names to guarentee name uniqueness, and
intend to do the same for SERIAL sequences.

The problem with this is that the OID value seems to change with each
run of the regression tests depending on when the last initdb was (in
the case of installcheck) or parallel events in the case of make
check.

There are two solutions that I can see.

One is to make the tests which have data that change in parallel mode
become serial tests (constraints, alter_table and foreign_key).
installcheck will continue to fail if not run immediatly after an
initdb however.

The other is to turn of NOTICE statements for regression tests,
instead displaying only error messages.


For those who are curious, the NOTICE statements in question are
displaying the auto-generated foreign key constraints which table
drops are cascading through.  Implicit drop notices (complex type on a
table) have already been removed.
--
Rod

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

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.
        regards, tom lane

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

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

It seems like a perfectly fine way to me.  I like it because it gives
predictable results (ie, same table schema will always be assigned the
same numbers), which the OID approach doesn't.  Also, if you want
something *guaranteed* unique then you must do this even with OIDs;
there's nothing stopping the user from declaring a constraint with
a name "foo_nnnnnnn" that happens to match the OID-based name you
invent for its unnamed sibling.

I suppose with lots and lots of constraints the O(N^2) time behavior
might start to be a problem, but there are probably ways around that
too --- say, keep a counter in analyze.c that starts at 1 for each new
CREATE TABLE, and is incremented each time you need to invent a
constraint name.  You still have to check-and-retry, but the expected
time is O(N) not O(N^2).
        regards, tom lane