From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | pgsql-patches(at)postgreSQL(dot)org |
Subject: | That dump-comments-on-composite-type-columns patch... |
Date: | 2004-08-06 18:27:45 |
Message-ID: | 22334.1091816865@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
... doesn't work.
$ pg_dump regression >zzz.out
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: "complex" is a composite type
pg_dump: The command was: COPY public.complex (r, i) TO stdout;
$
I suspect it had more subtle problems too, because dumpTableComments
would have attached the comments to the dumpid associated with the
TableInfo entry, which isn't the object that will get dumped. So it
seems moderately likely that there would have been a potential for
misordering of the output.
I think it's probably a fundamentally bad idea to be putting composite
types into pg_dump's TableInfo array, because they just really aren't
tables at all. If you want to try again, I'd suggest writing a variant
of dumpTableComment that takes a TypeInfo and the attribute-names query
data obtained by dumpCompositeType.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-08-06 18:36:57 | Re: UNICODE characters above 0x10000 |
Previous Message | J. Andrew Rogers | 2004-08-06 18:26:24 | Re: PostgreSQL as an application server |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-08-06 18:36:57 | Re: UNICODE characters above 0x10000 |
Previous Message | David Fetter | 2004-08-06 18:10:40 | Intro patch |