Re: pg_dump sort order for functions

I wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> On mn, 2010-01-11 at 12:54 -0500, Tom Lane wrote:
>>> -- Name: binary_coercible(oid, oid); Type: FUNCTION; Schema: public; Owner: postgres

>> Um, that tag is the "name", and if you change that, the name in CREATE
>> FUNCTION also changes.

> So?

Actually, we're talking at cross-purposes here. The tag I'm talking
about is the one generated via format_function_signature, and the
problem with what I had in mind is that it isn't done yet at the point
where the sort runs.

>> In the mean time, hacking it into the sort function itself as a special
>> case works out fine, per attached patch. One might frown upon such an
>> exception, but then again, function overloading is an exception to the
>> one-name-per-object rule all over the place anyway. ;-)

> No, that's a completely bogus solution, because it depends on type
> OIDs. It won't be stable across dump/reload, which defeats the purpose
> AFAICS.

You could probably make it work more safely if you applied
getFormattedTypeName() and then compared the string names.
That would be rather expensive :-( but in most databases
this should happen few enough times so it wouldn't be a problem.

[ thinks for a bit ... ] Although getFormattedTypeName depends on
the current search_path, so that might be a bit of an issue for
stability as well. I guess we could force a standardized path,
perhaps pg_catalog only, before sorting.

regards, tom lane