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
>>
>
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 |