BUG #4428: renaming tables, columns and fk cheks problem

The following bug has been logged online:

Bug reference:      4428
Logged by:          Taras Kopets
Email address:      tkopets@gmail.com
PostgreSQL version: 8.3.1
Operating system:   Win XP SP2
Description:        renaming tables, columns and fk cheks problem
Details:

-- a simple test case to reproduce the problem

CREATE TABLE fktest_a(a_id integer NOT NULL PRIMARY KEY);

CREATE TABLE fktest_b
(
   b_id integer NOT NULL,
   a_id integer NOT NULL,
    PRIMARY KEY (b_id),
    FOREIGN KEY (a_id) REFERENCES fktest_a (a_id)
);

INSERT INTO fktest_a VALUES(1);
INSERT INTO fktest_a VALUES(2);
INSERT INTO fktest_a VALUES(3);

INSERT INTO fktest_b VALUES(1,3);
INSERT INTO fktest_b VALUES(2,1);
INSERT INTO fktest_b VALUES(3,2);
INSERT INTO fktest_b VALUES(4,2);
INSERT INTO fktest_b VALUES(5,3);
-- INSERT INTO fktest_b VALUES(6,4);    --  error (fk violation), that's
good!


ALTER TABLE fktest_a RENAME TO fka;
ALTER TABLE fka RENAME a_id  TO aid;

ALTER TABLE fktest_b RENAME TO fkb;
ALTER TABLE fkb RENAME a_id  TO aid;
ALTER TABLE fkb RENAME b_id  TO bid;


INSERT INTO fkb VALUES(6,4);    --  stange error (see below)
-- ERROR: relation "public.fktest_a" does not exist
-- SQL state: 42P01
-- Context: SQL statement "SELECT 1 FROM ONLY "public"."fktest_a" x WHERE
"a_id" OPERATOR(pg_catalog.=) $1 FOR SHARE OF x"

-- but if we start new session and put the same insert statement we will get
our expected fk violation error


-- clean-up
-- DROP TABLE fkb;
-- DROP TABLE fka;

sorry to bother you if I'm wrong