Christian Rank wrote:
create table a (n integer);
create table b (n integer);
alter table a add primary key (n);
alter table b add foreign key (n) references a(n);
Have you considered using "on delete cascade" in table b?
--
jimoe at sohnen-moe dot com
-
Tom Lane wrote:
> Christian Rank <[EMAIL PROTECTED]> writes:
>
>>... according to the docs, the validity of a constraint should be
>>checked after each statement unless this behaviour is altered with a SET
>>CONSTRAINTS statement.
>
>
> "Statement" means "interactive command" in that context --
Christian Rank <[EMAIL PROTECTED]> writes:
> ... according to the docs, the validity of a constraint should be
> checked after each statement unless this behaviour is altered with a SET
> CONSTRAINTS statement.
"Statement" means "interactive command" in that context --- in other
words, the constra
Supposing you drop the "delete from b;" from the function, you'll find
that the function fails with much the same error message you had
before.
Evidently that foreign key check gets _deferred_ in the context of the
stored procedure. It is indeed checked; just not at the point you
expect it to be
Patrick Welche wrote:
> On Thu, May 13, 2004 at 11:41:24AM +0200, Christian Rank wrote:
>
>> create function f () returns void as '
>> begin
>>delete from a;
>>delete from b;
>>return;
>> end;
>> ' language plpgsql;
>>
>>I would expect that
>>
>> s
On Thu, May 13, 2004 at 11:41:24AM +0200, Christian Rank wrote:
> create function f () returns void as '
> begin
> delete from a;
> delete from b;
> return;
> end;
> ' language plpgsql;
>
> I would expect that
>
> select f();
>
> yields an er
Hello,
I came across the following problem with integrity constraints and
PL/pgSQL (PostgreSQL version used: 7.4.2):
I defined the following tables, constraints and data:
create table a (n integer);
create table b (n integer);
alter table a add primary key (n);
al
