I wrote:
> Peter Eisentraut <pete...@gmx.net> writes:
>> On mån, 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
