| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | tom(at)intevation(dot)de |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #15934: pg_dump output in wrong order if custom operator class is used as subtype_opclass in a range type |
| Date: | 2019-07-31 18:26:36 |
| Message-ID: | 29072.1564597596@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
I wrote:
> Clearly, we gotta upgrade pg_dump's intelligence about handling this
> dependency structure. The most straightforward fix would involve
> promoting pg_amop (and pg_amproc) entries to be full DumpableObjects,
> but I'm apprehensive about the overhead that would add ...
After further thought, I realized we could fix it far less invasively
than that, by teaching getDependencies() to translate pg_depend entries
for the pg_amop/amproc rows to look like dependencies for their parent
opfamily. This looks messy, but in a typical database without any
custom opclasses, it's actually really cheap, because there won't be
any pg_depend entries satisfying the classid conditions.
I wasn't looking forward to back-patching the other idea, but this
patch seems like it should be pretty painless.
Again, thanks for the report!
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| fix-dump-dependencies-for-custom-opclasses.patch | text/x-diff | 2.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-07-31 23:07:29 | Re: PostgreSQL12 crash bug report |
| Previous Message | Tom Lane | 2019-07-31 16:07:11 | Re: BUG #15934: pg_dump output in wrong order if custom operator class is used as subtype_opclass in a range type |