Re: Weird Trigger behaviour
От | Alvaro Herrera |
---|---|
Тема | Re: Weird Trigger behaviour |
Дата | |
Msg-id | Pine.LNX.4.44.0209201721310.24539-100000@cm-lcon1-46-187.cm.vtr.net обсуждение исходный текст |
Ответ на | Weird Trigger behaviour (Glen Eustace <geustace@godzone.net.nz>) |
Список | 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 по дате отправления: