Re: Diffrent column ordering after dump/restore tables with INHERITS

From: Oleg Serov <serovov(at)gmail(dot)com>
To: toruvinn <toruvinn(at)lain(dot)pl>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Diffrent column ordering after dump/restore tables with INHERITS
Date: 2009-07-05 09:28:25
Message-ID: cec7c6df0907050228m2578ffc3w4acbe246a5bd5d1f@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Here is the solution of this problem:
Patch

src/bin/pg_dump/pg_dump.c
appendPQExpBuffer(q, "CREATE TABLE %s (",
fmtId(tbinfo->dobj.name));
actual_atts = 0;
for (j = 0; j < tbinfo->numatts; j++)
{
/* Is this one of the table's own attrs, and not dropped ? */
- if (!tbinfo->inhAttrs[j] &&
- (!tbinfo->attisdropped[j] || binary_upgrade))
+ if (!tbinfo->attisdropped[j] || binary_upgrade)
{
/* Format properly if not first attr */
if (actual_atts > 0)
appendPQExpBuffer(q, ",");
appendPQExpBuffer(q, "\n ");

Before patch

CREATE TABLE "tmp"."stat_agg_all" (
"foo" BOOLEAN
) INHERITS ("prt4_stat"."stat_data", "prt4_stat"."stat_agg")
WITH OIDS;

After patch:

CREATE TABLE "tmp"."stat_agg_all" (
"foo" BOOLEAN,
"time" TIMESTAMP WITH TIME ZONE NOT NULL,
"banner_views" NUMERIC,
"ad_page_views" NUMERIC,
"phone_validate_views" NUMERIC,
"phone_validate_code_sended" NUMERIC,
"phone_validate_code_validate" NUMERIC,
"ad_form_views" NUMERIC,
"ad_form_submits" NUMERIC,
"ad_shop_select_views" NUMERIC,
"ad_emitted" NUMERIC,
"ad_redeemed" NUMERIC,
"client_payed" NUMERIC,
"mediapartner_charged" NUMERIC,
"ad_banner_views" NUMERIC,
"id" BIGINT NOT NULL,
"interval" "prt4_stat"."stat_enum_interval"
) INHERITS ("prt4_stat"."stat_data", "prt4_stat"."stat_agg")
WITH OIDS;

it well be okey!

On Sun, Jul 5, 2009 at 12:45 PM, Oleg Serov<serovov(at)gmail(dot)com> wrote:
> No, we can't do like this, because we have something like this:
>
> CREATE TABLE test_base (
>        id INT
> );
> CREATE TABLE test_child_with_data (
>        t TEXT
> ) INHERITS (test_base);
>
> ALTER TABLE test_base ADD COLUMN date DATE;
>
> INSERT INTO test_child_with_data VALUES (1, 'text', NOW());
>
> CREATE FUNCTION some_magic() RETURNS SETOF test_child_with_data AS
> $$
>        SELECT (SUM(id), t, MIN(date))::test_child_with_data
>        FROM test_child_with_data
>        GROUP BY t
> $$ LANGUAGE SQL;
>
>
> INSERT INTO test_child_with_data
>        SELECT * FROM some_magic(); -- Works fine.
>
>
> -- Dump/restore
>
>
> INSERT INTO test_child_with_data
>        SELECT * FROM some_magic(); -- Error.
>
>
> On Sun, Jul 5, 2009 at 4:48 AM, toruvinn<toruvinn(at)lain(dot)pl> wrote:
>> On Sat, 04 Jul 2009 22:10:55 +0200, Oleg Serov <serovov(at)gmail(dot)com> wrote:
>>>
>>> INSERT INTO test_child_with_data
>>>        SELECT 1, 'test', NOW(); -- works fine.
>>> -- Dump/restore
>>> INSERT INTO test_child_with_data
>>>        SELECT 1, 'test', NOW(); -- error..
>>
>> How about INSERT INTO test_child_with_data (id, t, date) SELECT 1, 'test',
>> NOW(); ? You'll won't have to care about order of the columns anymore.
>>
>> Best regards,
>> --
>> ru
>>
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2009-07-05 10:25:26 Re: BUG #4899: Open parenthesis breaks query plan
Previous Message Oleg Serov 2009-07-05 08:45:50 Re: Diffrent column ordering after dump/restore tables with INHERITS