Re: [HACKERS] Rethinking pg_dump's function sorting code

2015-03-06 Thread Tom Lane
Noah Misch n...@leadboat.com writes: Comparing argument type names sounds fine. Comparing argument type OID does not offer enough to justify the loss of cross-cluster sort equivalence. Fair enough. So as to stably compare f(nsp0.t) to f(nsp1.t), this should also compare the dobj.namespace

Re: [HACKERS] Rethinking pg_dump's function sorting code

2015-03-06 Thread Marko Tiikkaja
On 2015-03-06 01:28, Tom Lane wrote: In bug #12832 Marko Tiikkaja points out that commit 7b583b20b1c95acb621c71251150beef958bb603 created a rather unnecessary dump failure hazard, since it applies pg_get_function_identity_arguments() to every function in the database, even those that won't get

Re: [HACKERS] Rethinking pg_dump's function sorting code

2015-03-06 Thread Noah Misch
On Thu, Mar 05, 2015 at 07:28:33PM -0500, Tom Lane wrote: In bug #12832 Marko Tiikkaja points out that commit 7b583b20b1c95acb621c71251150beef958bb603 created a rather unnecessary dump failure hazard, since it applies pg_get_function_identity_arguments() to every function in the database, even

[HACKERS] Rethinking pg_dump's function sorting code

2015-03-05 Thread Tom Lane
In bug #12832 Marko Tiikkaja points out that commit 7b583b20b1c95acb621c71251150beef958bb603 created a rather unnecessary dump failure hazard, since it applies pg_get_function_identity_arguments() to every function in the database, even those that won't get dumped. I think we should fix this by