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.6010...@yahoo.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
