Skip site navigation (1) Skip section navigation (2)

Re: pg_dump sort order for functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump sort order for functions
Date: 2010-01-13 18:21:21
Message-ID: 28192.1263406881@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2010-01-13 18:24:22
Subject: Hot Standby and query cancel
Previous:From: Josh BerkusDate: 2010-01-13 18:16:21
Subject: Re: plpython3

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group