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

2015-03-06 Thread Tom Lane
Noah Misch 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 name. Ah, good

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

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 du

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