X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id E7E90D1B381 for ; Tue, 20 Jul 2004 23:45:29 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 56615-06 for ; Wed, 21 Jul 2004 02:45:28 +0000 (GMT) Received: from news.hub.org (news.hub.org [200.46.204.72]) by svr1.postgresql.org (Postfix) with ESMTP id 41121D1B2E0 for ; Tue, 20 Jul 2004 23:45:23 -0300 (ADT) Received: from news.hub.org (news.hub.org [200.46.204.72]) by news.hub.org (8.12.9/8.12.9) with ESMTP id i6L2jMqd058473 for ; Wed, 21 Jul 2004 02:45:23 GMT (envelope-from news@news.hub.org) Received: (from news@localhost) by news.hub.org (8.12.9/8.12.9/Submit) id i6L2Ma8L055380 for pgsql-sql@postgresql.org; Wed, 21 Jul 2004 02:22:36 GMT From: Jeff Boes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 X-Newsgroups: comp.databases.postgresql.sql Subject: Inherited tables and new fields Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lines: 44 Message-ID: Date: Tue, 20 Jul 2004 10:36:02 -0400 To: pgsql-sql@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.6 tagged_above=0.0 required=5.0 tests=DATE_IN_PAST_06_12 X-Spam-Level: X-Archive-Number: 200407/136 X-Sequence-Number: 18388 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 <>< jboes@qtm.net