Tom Lane wrote:
What PG version are you using?
8.2.11
In 8.3 it seems to work automatically,
although in prior versions you could well have some problems with cached
plans not getting invalidated.
Any proposed workaround?
Would SELECTs be affected by this too?
(detaild log message from pg_log
2009-05-15 00:00:17.179 CEST> LOCATION: make_inh_translation_lists,
prepunion.c:992
2009-05-15 00:00:17.179 CEST> STATEMENT:
UPDATE state_change SET (final_view_time, end_time) =
(226, 10528) WHERE id = 91332641 AND time = 10523
2009-05-15 00:00:17.179 CEST> ERROR: XX000: could not find inherited
attribute "id" of relation "state_change_20090430")
FWIW, we have implemented a trial solution to your original complaint
for 8.4:
http://archives.postgresql.org/pgsql-committers/2009-05/msg00208.php
Nice :-) Although for now I will need to get this working on 8.2.x.
Does this leave me with UPDATE triggers as the best viable (is it
viable?) solution?
Are there, as mentioned in previous post, some way to simulate the way
the DB behaved when using rules for partitioning?
Best Regards
Thomas
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
