This feels like a flaw in the way inherited tables work.
I have a "template" table used to create other tables (but not by
inheritance; instead the "daughter" tables are created via
create table draft_00123 as select * from draft_template where false;
This is done for somewhat historical reasons, because we weren't sure at
the time if we were going to stay with Pg and so we didn't use every
Pg-specific feature in the books.
Of course, we regret that ...
Now we have a function that spans all the daughter tables. That is, you
can do
select * from fn_all_drafts() ...
and get rows from each table.
Of course, had we used table inheritance, we'd do something like ...
select * from draft_template ...
but it wouldn't do exactly what we are doing now: that is,
fn_all_drafts() returns not only the contents of every row in the tables
draft_XXXXX, but also an extra column indicating which table that row
came from.
create table all_drafts (editor_id integer) inherits draft_template;
What frustrates me from time to time is that if "draft_template" is
altered to add a new column, then the function breaks because the new
column appears in "all_drafts" as *following* editor_id. The column
order messes up the code in the function, because it's expecting
all_drafts to look like draft_template, with editor_id added at the end.
Is this a mis-feature?
--
(Posted from an account used as a SPAM dump. If you really want to get
in touch with me, dump the 'jboes' and substitute 'mur'.)
________
Jeffery Boes <>< [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
