From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andreas Karlsson <andreas(at)proxel(dot)se> |
Cc: | Joel Jacobson <joel(at)gluefinance(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Jim Nasby <jim(at)nasby(dot)net>, Herrera Alvaro <alvherre(at)commandprompt(dot)com>, pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bug in pg_describe_object |
Date: | 2011-01-12 00:14:58 |
Message-ID: | 11595.1294791298@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andreas Karlsson <andreas(at)proxel(dot)se> writes:
> On Tue, 2011-01-11 at 14:01 -0500, Tom Lane wrote:
>> It really shouldn't be useful to include those. Attend what it says in
>> the fine manual for CREATE OPERATOR CLASS:
> Hm, that is not what I see when reading the source.
> There can exist several entries in pg_amproc for one operator family
> with the same short_number and function (both name and types).
We're cheating in a small number of places by using a binary-compatible
hash function to implement hashing for a datatype other than the one
it's declared to work on. I don't think that the existence of that hack
means that getObjectDescription should bloat the descriptions of every
amproc entry with generally-useless information.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2011-01-12 00:17:05 | Re: arrays as pl/perl input arguments [PATCH] |
Previous Message | Tom Lane | 2011-01-12 00:04:47 | Re: Something fishy about the current Makefiles |