From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bug when dumping "empty" operator classes |
Date: | 2017-05-26 15:08:05 |
Message-ID: | 30099.1495811285@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> While hacking on pg_upgrade in downstream Greenplum I ran into an error which
> seems like an old, and obscure, bug in pg_dump (unrelated to pg_upgrade).
> pg_dump generates incorrect SQL for an operator class which has no operators or
> procedures, and which has the same column and storage types.
Good catch.
> The attached patch adds a belts-and-suspenders check in dumpOpclass() which
> appends the STORAGE clause in case nothing had been added.
Seems reasonable (the comment could use some wordsmithing maybe) ...
> ... The DROP in
> alter_generic is also removed to exercise the code path, being able to
> pg_upgrade what is executed in regression seem like a good idea.
... but that's a nonstarter. We can't have the regression tests leaving
global objects (users) lying around.
I'll commit and back-patch this without a test case. Possibly Frost will
be excited enough about it to add something to the pg_dump TAP tests,
but those tests are too opaque for me to want to do so.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2017-05-26 15:14:19 | Re: Bug when dumping "empty" operator classes |
Previous Message | Petr Jelinek | 2017-05-26 15:04:13 | Re: logical replication - still unstable after all these months |