* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > As pointed out by Peter E, this also impacts CASTs. Attached is a patch > > which addresses both by simply also pulling any functions which are > > referenced from pg_cast or pg_transform when they have OIDs at or after > > FirstNormalObjectId. I also modified dumpCast() and dumpTransform() to > > complain loudly if they're unable to dump out the cast or transform due > > to not finding the function definition(s) necessary. > > Please do not hack the already-overcomplicated query in getFuncs without > bothering to adjust the long comment that describes what it's doing.
Right, just wanted to make sure no one had issue with this approach. > I have a vague feeling that the code for dumping casts and/or transforms > may have some assumptions that the underlying function is also being > dumped. Although maybe the assumption was really only what's fixed here, > ie that there be a DumpableObject for the function. Anyway, take a close > look for that. I'll look around and see, though my hunch is that, at some point, we were just pulling all functions and then an optimization was added to exclude pg_catalog and no one noticed that it broke casts using built-in functions. > Looks reasonable otherwise. Ok, great, I'll get to work on building and testing all supported versions of pg_dump vs. all server versions that I can reasonably get to build on my current laptop, which I expect to be a matrix of 9.2-master pg_dump against server versions ~7.4-master... Thanks! Stephen
signature.asc
Description: Digital signature
