Re: [HACKERS] pg_dump and inherited attributes

Hi,

I'm looking at pg_dump/common.c:flagInhAttrs() and suspect that it can
be more or less rewritten completely, and probably should to get rigth
all the cases mentioned in the past attisinherited discussion. Is this
desirable for 7.3? It can probably be hacked around and the rewrite
kept for 7.4, but I think it will be much simpler after the rewrite.

What do people think about this?

--
Alvaro Herrera (<alvherre[a]atentus.com>)
"Siempre hay que alimentar a los dioses, aunque la tierra este seca" (Orual)

Alvaro Herrera <alvherre(at)atentus(dot)com> writes:
> I'm looking at pg_dump/common.c:flagInhAttrs() and suspect that it can
> be more or less rewritten completely, and probably should to get rigth
> all the cases mentioned in the past attisinherited discussion. Is this
> desirable for 7.3? It can probably be hacked around and the rewrite
> kept for 7.4, but I think it will be much simpler after the rewrite.

If it's a bug then it's fair game to fix in 7.3. But keep in mind that
pg_dump has to behave at least somewhat sanely when called against older
servers ... will your rewrite behave reasonably if the server does not
offer attinhcount values?

regards, tom lane

En Wed, 25 Sep 2002 00:01:24 -0400
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> escribió:

> Alvaro Herrera <alvherre(at)atentus(dot)com> writes:
> > I'm looking at pg_dump/common.c:flagInhAttrs() and suspect that it can
> > be more or less rewritten completely, and probably should to get rigth
> > all the cases mentioned in the past attisinherited discussion. Is this
> > desirable for 7.3? It can probably be hacked around and the rewrite
> > kept for 7.4, but I think it will be much simpler after the rewrite.
>
> If it's a bug then it's fair game to fix in 7.3. But keep in mind that
> pg_dump has to behave at least somewhat sanely when called against older
> servers ... will your rewrite behave reasonably if the server does not
> offer attinhcount values?

Nah. I don't think it's worth it: I had forgotten that older versions
should be supported. I just left the code as is and added a
version-specific test.

This patch allows pg_dump to dump correctly local definition of columns.
In particular,

CREATE TABLE p1 (f1 int, f2 int);
CREATE TABLE p2 (f1 int);
CREATE TABLE c () INHERITS (p1, p2);
ALTER TABLE ONLY p1 DROP COLUMN f1;
CREATE TABLE p3 (f1 int);
CREATE TABLE c2 (f1 int) INHERITS (p3);

Will be dumped as
CREATE TABLE p1 (f2 int);
CREATE TABLE p2 (f1 int);
CREATE TABLE c (f1 int) INHERITS (p1, p2);
CREATE TABLE c2 (f1 int) INHERITS (p3);

(Previous version will dump
CREATE TABLE c () INHERITS (p1, p2)
CREATE TABLE c2 () INHERITS (p3) )

--
Alvaro Herrera (<alvherre[a]atentus.com>)
A male gynecologist is like an auto mechanic who never owned a car.
- Carrie Snow

Your patch has been added to the PostgreSQL unapplied patches list at:

http://candle.pha.pa.us/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------

Alvaro Herrera wrote:
> En Wed, 25 Sep 2002 00:01:24 -0400
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> escribi?:
>
> > Alvaro Herrera <alvherre(at)atentus(dot)com> writes:
> > > I'm looking at pg_dump/common.c:flagInhAttrs() and suspect that it can
> > > be more or less rewritten completely, and probably should to get rigth
> > > all the cases mentioned in the past attisinherited discussion. Is this
> > > desirable for 7.3? It can probably be hacked around and the rewrite
> > > kept for 7.4, but I think it will be much simpler after the rewrite.
> >
> > If it's a bug then it's fair game to fix in 7.3. But keep in mind that
> > pg_dump has to behave at least somewhat sanely when called against older
> > servers ... will your rewrite behave reasonably if the server does not
> > offer attinhcount values?
>
> Nah. I don't think it's worth it: I had forgotten that older versions
> should be supported. I just left the code as is and added a
> version-specific test.
>
> This patch allows pg_dump to dump correctly local definition of columns.
> In particular,
>
> CREATE TABLE p1 (f1 int, f2 int);
> CREATE TABLE p2 (f1 int);
> CREATE TABLE c () INHERITS (p1, p2);
> ALTER TABLE ONLY p1 DROP COLUMN f1;
> CREATE TABLE p3 (f1 int);
> CREATE TABLE c2 (f1 int) INHERITS (p3);
>
> Will be dumped as
> CREATE TABLE p1 (f2 int);
> CREATE TABLE p2 (f1 int);
> CREATE TABLE c (f1 int) INHERITS (p1, p2);
> CREATE TABLE c2 (f1 int) INHERITS (p3);
>
> (Previous version will dump
> CREATE TABLE c () INHERITS (p1, p2)
> CREATE TABLE c2 () INHERITS (p3) )
>
> --
> Alvaro Herrera (<alvherre[a]atentus.com>)
> A male gynecologist is like an auto mechanic who never owned a car.
> - Carrie Snow

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Patch applied. Thanks.

---------------------------------------------------------------------------

Alvaro Herrera wrote:
> En Wed, 25 Sep 2002 00:01:24 -0400
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> escribi?:
>
> > Alvaro Herrera <alvherre(at)atentus(dot)com> writes:
> > > I'm looking at pg_dump/common.c:flagInhAttrs() and suspect that it can
> > > be more or less rewritten completely, and probably should to get rigth
> > > all the cases mentioned in the past attisinherited discussion. Is this
> > > desirable for 7.3? It can probably be hacked around and the rewrite
> > > kept for 7.4, but I think it will be much simpler after the rewrite.
> >
> > If it's a bug then it's fair game to fix in 7.3. But keep in mind that
> > pg_dump has to behave at least somewhat sanely when called against older
> > servers ... will your rewrite behave reasonably if the server does not
> > offer attinhcount values?
>
> Nah. I don't think it's worth it: I had forgotten that older versions
> should be supported. I just left the code as is and added a
> version-specific test.
>
> This patch allows pg_dump to dump correctly local definition of columns.
> In particular,
>
> CREATE TABLE p1 (f1 int, f2 int);
> CREATE TABLE p2 (f1 int);
> CREATE TABLE c () INHERITS (p1, p2);
> ALTER TABLE ONLY p1 DROP COLUMN f1;
> CREATE TABLE p3 (f1 int);
> CREATE TABLE c2 (f1 int) INHERITS (p3);
>
> Will be dumped as
> CREATE TABLE p1 (f2 int);
> CREATE TABLE p2 (f1 int);
> CREATE TABLE c (f1 int) INHERITS (p1, p2);
> CREATE TABLE c2 (f1 int) INHERITS (p3);
>
> (Previous version will dump
> CREATE TABLE c () INHERITS (p1, p2)
> CREATE TABLE c2 () INHERITS (p3) )
>
> --
> Alvaro Herrera (<alvherre[a]atentus.com>)
> A male gynecologist is like an auto mechanic who never owned a car.
> - Carrie Snow

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073