Re(2): Re(2): REFERENCES fails on derived classes

great, thank you much. i wanted to know, in part, that i hadn't missed
something. i'm going to use the same serial and hope that values aren't
entered in the Id field (i won't provide a way to do it in my client app,
so it should be safe enough). but the extra security is valuable to me,
to cover all my bases. so i'd appreciate it being confirmed as "covered"
by one bug report or enhancement request or another. then, when it
becomes available, i'll put the extra securities in. perhaps someday i'll
be able to help work on it, or some other part of postgress! right now
i'm working on another freeware project so i don't have time, but.....
(and if this is still an open request when i do, i'll gladly take it on!)

thanks again, you've been quite helpful,
jmichael

sszabo(at)megazone23(dot)bigpanda(dot)com writes:
>Unfortunately there's no way within the current constraints to do that
>kind of unique constraint, although you should get actually unique numbers
>out of the serial -- and those will span the two tables since it uses the
>same sequence, you can't guarantee that explicitly placed values will be
>unique. This is probably a bug, but inheritance needs alot of work in
>general.
>
>You might be able fake it with a insert/update trigger in plpgsql
>that makes sure that there are no matching rows. It wouldn't exactly
>be the same thing as a unique constraint, but it'd probably be close
>enough for most use.
>