Re(2): Re(2): REFERENCES fails on derived classes - Mailing list pgsql-bugs

From Michael Caine
Subject Re(2): Re(2): REFERENCES fails on derived classes
Date
Msg-id fc.000f4b1100146d9d3b9aca00c10327eb.146da7@artlogic.com
Whole thread Raw
In response to Re: Re(2): REFERENCES fails on derived classes  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
List pgsql-bugs
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@megazone23.bigpanda.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.
>

pgsql-bugs by date:

Previous
From: meeta bhate
Date:
Subject: Re: Information regarding foriegn key constraint.
Next
From: pgsql-bugs@postgresql.org
Date:
Subject: coalesce in execute crashes backend