Re: Bug in CVS pg_dump against 7.0.x - Mailing list pgsql-patches
From | Bruce Momjian |
---|---|
Subject | Re: Bug in CVS pg_dump against 7.0.x |
Date | |
Msg-id | 200405190422.i4J4MdP13183@candle.pha.pa.us Whole thread Raw |
In response to | Re: Bug in CVS pg_dump against 7.0.x (Christopher Kings-Lynne <chriskl@familyhealth.com.au>) |
List | pgsql-patches |
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --------------------------------------------------------------------------- Christopher Kings-Lynne wrote: > No, the patch is against 7.5 CVS. It is a tiny fix that allows it to > dump 7.0.x database backends correctly. > > I submitted a fix for 7.5 dumping 7.0 previously and it was accepted :) > > Chris > > Bruce Momjian wrote: > > > Uh, not sure anyone would even see a 7.0.X release if we made it, and I > > question how many are using varying[]. Your patch is now in the > > archives, and we can point folks to it if they ask. > > > > --------------------------------------------------------------------------- > > > > Christopher Kings-Lynne wrote: > > > >>Hi, > >> > >>I know 7.0.x is pretty old, but I'm wondering if we should fix this to > >>make it better for people upgrading. > >> > >>If you create a table like this in 7.0.x: > >> > >>CREATE TABLE address ( > >> first_name character varying(50) DEFAULT 'asdf' NOT NULL, > >> last_name character varying(50) NOT NULL, > >> address character varying(50), > >> tesing character varying[] > >>); > >> > >>The 7.5 pg_dump program will dump it like this: > >> > >>CREATE TABLE address ( > >> first_name character varying(50) DEFAULT 'asdf' NOT NULL, > >> last_name character varying(50) NOT NULL, > >> address character varying(50), > >> tesing _varchar > >>); > >> > >>I have attached a patch that should fix it. I haven't been able to > >>actually test it since my dev machine and the 7.0 machine I have access > >>to aren't connected - although it does compile. The fix is based on the > >>7.0 psql code. > >> > >>Chris > > > > > >>? src/bin/pg_dump/.deps > >>? src/bin/pg_dump/common.c.working > >>? src/bin/pg_dump/pg_dump > >>? src/bin/pg_dump/pg_dump.c.working > >>? src/bin/pg_dump/pg_dump.h.working > >>? src/bin/pg_dump/pg_dumpall > >>? src/bin/pg_dump/pg_restore > >>Index: src/bin/pg_dump/pg_dump.c > >>=================================================================== > >>RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_dump/pg_dump.c,v > >>retrieving revision 1.370 > >>diff -c -r1.370 pg_dump.c > >>*** src/bin/pg_dump/pg_dump.c 24 Mar 2004 03:06:08 -0000 1.370 > >>--- src/bin/pg_dump/pg_dump.c 16 May 2004 14:42:55 -0000 > >>*************** > >>*** 7726,7733 **** > >>--- 7726,7741 ---- > >> myFormatType(const char *typname, int32 typmod) > >> { > >> char *result; > >>+ bool isarray = false; > >> PQExpBuffer buf = createPQExpBuffer(); > >> > >>+ /* Handle array types */ > >>+ if (typname[0] == '_') > >>+ { > >>+ isarray = true; > >>+ typname++; > >>+ } > >>+ > >> /* Show lengths on bpchar and varchar */ > >> if (!strcmp(typname, "bpchar")) > >> { > >>*************** > >>*** 7770,7775 **** > >>--- 7778,7787 ---- > >> appendPQExpBuffer(buf, "\"char\""); > >> else > >> appendPQExpBuffer(buf, "%s", fmtId(typname)); > >>+ > >>+ /* Append array qualifier for array types */ > >>+ if (isarray) > >>+ appendPQExpBuffer(buf, "[]"); > >> > >> result = strdup(buf->data); > >> destroyPQExpBuffer(buf); > > > > > >>---------------------------(end of broadcast)--------------------------- > >>TIP 5: Have you checked our extensive FAQ? > >> > >> http://www.postgresql.org/docs/faqs/FAQ.html > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
pgsql-patches by date: