From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: That dump-comments-on-composite-type-columns patch... |
Date: | 2004-08-08 04:53:19 |
Message-ID: | 4115B1BF.6020509@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
> $ 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;
> $
That could be fixed by just checking the relkind when dumping table
data, but hey.
> 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.
Ok.
> 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.
You mean unlike views, sequences and all other kinds of junk? :)
OK, I can do this, but I don't think I'll have time for the first beta.
Chris
ps. Did you back out the moving of owner to commands as well?
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-08-08 04:55:42 | Re: log file rotate |
Previous Message | Christopher Kings-Lynne | 2004-08-08 04:51:12 | Re: listing triggers |
From | Date | Subject | |
---|---|---|---|
Next Message | markir | 2004-08-08 05:23:08 | Re: Win32 tablespace |
Previous Message | Bruce Momjian | 2004-08-08 03:59:25 | Re: Win32 tablespace |