On Sun, Jan 16, 2011 at 2:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andreas Karlsson <andreas@proxel.se> writes:
>> On Sat, 2011-01-15 at 10:36 -0500, Tom Lane wrote:
>>> But I can read the handwriting on the wall: if I want this done right,
>>> I'm going to have to do it myself.
>
>> Do I understand you correctly if I interpret what you would like to see
>> is the same format used now in these cases?
>
> Attached is a patch that does what I would consider an acceptable job of
> printing these datatypes only when they're interesting. I still think
> that this is largely a waste of code, but if people want it, this is
> what to do. Testing this in the regression database, it fires on
> (a) the entries where a binary-compatible hash function is used, and
> (b) all the entries associated with the GIN operator family array_ops.
> The latter happens because we've more or less arbitrarily crammed a
> bunch of opclasses into the same opfamily.
>
> One other point here is that I find messages like this a mite
> unreadable:
>
> function 1 (oidvector[], oidvector[]) btoidvectorcmp(oidvector,oidvector) of operator family array_ops for access
methodgin
>
> If we were to go with this, I'd be strongly tempted to rearrange all
> four of the messages involved to put the operator or function name
> at the end, eg
>
> function 1 (oidvector[], oidvector[]) of operator family array_ops for access method gin:
btoidvectorcmp(oidvector,oidvector)
>
> Comments?
I kind of wonder if it wouldn't be even better to just *delete* that
from the thing altogether and write:
function 1 (oidvector[], oidvector[]) of operator family array_ops for
access method gin
We're trying to represent the pg_amproc entry here, and including a
bunch of details of the pg_proc entry to which it happens to point
seems almost better to be confusing the issue. The key for pg_amproc
is the operator family, the left and right argument types, and the
proc number, so it seems like those are the things we ought to be
printing.
But if you want to keep it, by all means let's put it at the end.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
