Joel Jacobson wrote: > On Wed, Oct 17, 2012 at 11:43 PM, Alvaro Herrera > <alvhe...@2ndquadrant.com> wrote: > > Uh, the patch you posted keeps the pg_get_function_identity_arguments > > call in dumpFunc, but there is now also a new one in getFuncs. Do we > > need to remove the second one? > > It could be done, but unfortunately we cannot use the value computed > in dumpFunc(), > because getFuncs() is called before dumpFunc().
Right, I got that from the discussion. > What could be done is to keep the changes in getFuncs(), and also > change dumpFunc() > to use the value computed in getFuncs(), but I think the gain is small > in relation > to the complexity of changing dumpFunc(), as we would still need to > make the two other > function calls in the SQL query in dumpFunc() to pg_get_function_arguments() > and > pg_get_function_result(). Changing pg_dump is complex enough whatever the change, yes. I have not touched this. > > Here's an updated patch for your consideration. I was about to push > > this when I noticed the above. The only change here is that the extra > > code that tests for new remoteVersions in the second "else if" branch of > > getFuncs and getAggregates has been removed, since it cannot ever be > > reached. > > Looks really good. Thanks, pushed it. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
