Fixing pg_dump's heuristic about casts

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Fixing pg_dump's heuristic about casts
Date: 2015-02-10 16:08:55
Message-ID: 28437.1423584535@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I was reminded today by Greg Mullane's blog post
http://blog.endpoint.com/2015/02/postgres-custom-casts-and-pgdump.html
about how pg_dump fails to dump custom casts if they are casts between
built-in types. Setting aside the wisdom of creating such a cast,
it's definitely annoying that pg_dump misses it. He's hardly the
first to complain, too.

The current heuristic dates back to this discussion:
http://www.postgresql.org/message-id/flat/3F7066BF(dot)6010100(at)Yahoo(dot)com
(see commit a6790ce85752b67ad994f55fdf1a450262ccc32e). Re-reading it,
I'm wondering why we didn't go with plan B, namely determine whether
to dump a cast based on its OID. That is, dump it if it has an OID >=
FirstNormalObjectId (16384), otherwise not. That's admittedly pretty
ugly, but the existing heuristic isn't exactly beautiful. And it's not
like we haven't used the OID rule for other things --- see extensions.

So I propose ripping out the current heuristic (in HEAD, lines 10482-10530
of pg_dump.c) and instead inspecting the cast's OID to decide whether to
dump it, much like selectDumpableExtension() does.

I'd further propose back-patching this fix.

Comments?

regards, tom lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-02-10 16:49:58 Re: parallel mode and parallel contexts
Previous Message Greg Sabino Mullane 2015-02-10 15:55:07 Better error message on pg_upgrade checksum mismatches