Re: Triggers failing from 7.0.2 to 7.1.3

Danny Aldham <danny(at)lennon(dot)postino(dot)com> writes:
> When an update is done to the package table, it appears that it
> has actually done an insert of the new record but not deleted the
> old record. So I end up with an extra record. If I define the tables
> without the trigger, the updates execute correctly.

I think what's really going on is not that the triggers have changed
behavior, but that SELECT has changed behavior. You defined your log
table as a child of the data table:

create table mupack (
xfop varchar,
xfstat varchar,
xftm timestamp
) inherits (package);

Beginning in 7.1, "SELECT FROM package" really means "SELECT FROM package*"
... that is, it selects over child tables too, so you see the log
records along with the package records. You need to write "SELECT FROM
ONLY package" to get the SELECT to look only at the parent table.

I believe there is a configuration variable you can set to get the old
behavior by default, but in the long run the best bet is probably not to
use inheritance simply as a way to save typing duplicate column
definitions. The new SELECT behavior really enforces the worldview that
says a parent/child table relationship is like a superclass/subclass
relationship. We haven't yet extended that to other behaviors (say,
making unique indexes extend over both tables), but I foresee that sort
of thing happening eventually.

Alternatively, you could make package and mupack inherit separately from
a common ancestor table. That'd allow you to avoid duplicating the
column definitions without getting the unwanted SELECT behavior when you
query the package table.

regards, tom lane