Hi!
On Mon, Apr 03, 2006 at 11:56:13PM +0100, Robert Watson wrote:
> >>This is why it's disabled by default, and the jail documentation
> >>specifically advises of this possibility. Excerpt below.
> >
> >Ah, I see, glad to see it's accurately documented.
>
> As it has been for the last five ye
hi, there!
On Mon, 23 Apr 2001, Jan Wieck wrote:
> I just got trapped by one of my own features in the
> referential integrity area.
>
> The problem is, that the trigger run on the FK row at UPDATE
> allways checks and locks the referenced PK, even if the FK
>
hi, there!
On Mon, 22 Jan 2001, Bruce Momjian wrote:
>
> > This problem with foreign keys has been reported to me, and I have confirmed
> > the bug exists in current sources. The DELETE should succeed:
> >
> > ---
> >
>
hi, there!
test=> create table foo(id int primary key);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'foo_pkey'
for table 'foo'
CREATE
test=> insert into foo values(1);
INSERT 88959 1
test=> create table bar(id int references foo);
NOTICE: CREATE TABLE will create implicit trigge
hi, there!
test=# create table a(id int primary key);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'a_pkey' for
table 'a'
CREATE
test=# create table b(id int references a);
NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY
check(s)
CREATE
test=# insert into a v
hi, there!
test=# create table a(id int primary key);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'a_pkey' for
table 'a'
CREATE
test=# create table b(id int references a);
NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY
check(s)
CREATE
test=# insert into a v
