Re: Weird Trigger behaviour - Mailing list pgsql-general

From Alvaro Herrera
Subject Re: Weird Trigger behaviour
Date
Msg-id Pine.LNX.4.44.0209201721310.24539-100000@cm-lcon1-46-187.cm.vtr.net
Whole thread Raw
In response to Weird Trigger behaviour  (Glen Eustace <geustace@godzone.net.nz>)
List pgsql-general
Glen Eustace dijo:

> I have a small table with a unique primary key and a second history
> table that inherits the first and add a modification tstamp.

> When I update a row in the table, I get a duplicate created. i.e. the
> update does an insert which allows the duplicate key. I also get the
> correct record in the history table.

This is the expected behavior.  When you do this

> netdbase=> select * from vlan;
>  id | name  | site |     network      |     gateway
> ----+-------+------+------------------+-----------------
>   1 | No Ok | TUR  | 130.123.104.0/22 | 130.123.104.200
>   1 | Here  | TUR  | 130.123.104.0/22 | 130.123.104.200
> (2 rows)

the rows from both tables are returned.  If you want only the parent
table, you have to use

SELECT * from ONLY vlan;

This behavior changed in 7.1 or so, where you had to indicate that you
wanted to recurse to child tables; in 7.1 and later, you have to
indicate that you do _not_ want to recurse.

There is a known bug in that the inheritance allows you to bypass the
uniqueness check.  This issue and others are being discussed, but won't
be fixed in 7.3 (maybe 7.4 or later)

--
Alvaro Herrera (<alvherre[a]atentus.com>)
"Some men are heterosexual, and some are bisexual, and some
men don't think about sex at all... they become lawyers" (Woody Allen)


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Getting acces to MVCC version number
Next
From: "Oleg Lebedev"
Date:
Subject: DBLink: interesting issue