| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | Ryan Kelly <rpkelly22(at)gmail(dot)com>, joe <joe(at)tanga(dot)com>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #6699: pg_restore with -j -- doesn't restore view that groups by primary key |
| Date: | 2012-06-20 02:34:15 |
| Message-ID: | 14084.1340159655@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
I wrote:
> We could possibly hack something for the special case of rules, but
> I don't think this would be the last time we hear about this type of
> issue. I'm inclined to think that the best solution would be to add
> generic logic to pg_dump that "looks through" any dependency references
> to objects that are not going to be dumped, and replaces them with the
> IDs of any objects they depend on that are going to be dumped.
I wrote a trial patch that does things that way (attached) and it
appears to work and solve the problem. However, it's not committable
as-is because it breaks the build of pg_restore:
ld: Unsatisfied symbols:
findObjectByDumpId (code)
since findObjectByDumpId is in common.c which isn't linked into
pg_restore. I guess a brute force solution would be to link it,
but probably we ought to think about refactoring the code to avoid
that. I'm not coming up with any very nice ideas about exactly how
to refactor, though. Thoughts?
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| expand-dump-dependencies-1.patch | text/x-patch | 3.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2012-06-20 02:56:30 | Re: BUG #6699: pg_restore with -j -- doesn't restore view that groups by primary key |
| Previous Message | Tom Lane | 2012-06-20 01:26:35 | Re: BUG #6699: pg_restore with -j -- doesn't restore view that groups by primary key |