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

Поиск
Список
Период
Сортировка
От Michael Caine
Тема Re(2): Re(2): REFERENCES fails on derived classes
Дата
Msg-id fc.000f4b1100146d9d3b9aca00c10327eb.146da7@artlogic.com
обсуждение исходный текст
Ответ на Re: Re(2): REFERENCES fails on derived classes  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
Список 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 по дате отправления:

Предыдущее
От: meeta bhate
Дата:
Сообщение: Re: Information regarding foriegn key constraint.
Следующее
От: pgsql-bugs@postgresql.org
Дата:
Сообщение: coalesce in execute crashes backend