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
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 |