Re: Is this the expected behaviour for DDL-query execution? - Mailing list pgsql-bugs

From Thomas Johansson
Subject Re: Is this the expected behaviour for DDL-query execution?
Date
Msg-id 4A0D2FD2.1060508@agama.tv
Whole thread Raw
In response to Re: Is this the expected behaviour for DDL-query execution?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Is this the expected behaviour for DDL-query execution?
List pgsql-bugs
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

pgsql-bugs by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Sorting dates
Next
From: Dave Page
Date:
Subject: Perl 5.10 vs. PG 8.4 on Win32