From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Rod Taylor" <rbt(at)zort(dot)ca> |
Cc: | "Hackers List" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Regression tests and NOTICE statements |
Date: | 2002-05-09 13:59:35 |
Message-ID: | 19091.1020952775@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Rod Taylor" <rbt(at)zort(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | mlw | 2002-05-09 14:05:03 | Re: How much work is a native Windows application? |
Previous Message | Michael Alan Dorman | 2002-05-09 13:55:48 | Re: Queries using rules show no rows modified? |