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 cov
On Mon, 11 Jun 2001, Michael Caine wrote:
> a month i was told that my possible bug submission was "sort of" a bug.
> the report and reply are below.
>
> now i write a follow up because i don't know how to establish a workroom.
> specifically, i know know that a unique constraint must be added
a month i was told that my possible bug submission was "sort of" a bug.
the report and reply are below.
now i write a follow up because i don't know how to establish a workroom.
specifically, i know know that a unique constraint must be added to an
inherited "id" field, even if it's a primary k
[EMAIL PROTECTED] writes:
>Add a unique constraint to t1d(id) and it should work.
ahh, great. thank you! (does this mean that the derived class' field's
data may be allowed to be non-unique? interesting. thank you.
---(end of broadcast)---
TIP
On Sat, 2 Jun 2001, J. Michael Caine wrote:
> the following works:
>
> create table t1 (id serial primary key);
> create table t2 (id serial primary key);
> create table t12 (
> t1_id int references t1(id) on delete cascade,
> t2_id int references t2(id) on delete cascade
> );
>
> b
the following works:
create table t1 (id serial primary key);
create table t2 (id serial primary key);
create table t12 (
t1_id int references t1(id) on delete cascade,
t2_id int references t2(id) on delete cascade
);
but the following does not:
create table t1d () inherits(t1);
