Re: Bug in pg_describe_object

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-11 19:01:49
Message-ID: 6406.1294772509@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:
> So would anyone be confused by a description of pg_amproc not including
> the types?

It really shouldn't be useful to include those. Attend what it says in
the fine manual for CREATE OPERATOR CLASS:

In a FUNCTION clause, the operand data type(s) the function is
intended to support, if different from the input data type(s) of
the function (for B-tree and hash indexes) or the class's data
type (for GIN and GiST indexes). These defaults are always
correct, so there is no point in specifying op_type in a
FUNCTION clause in CREATE OPERATOR CLASS, but the option is
provided for consistency with the comparable syntax in ALTER
OPERATOR FAMILY.

The reason the ALTER OPERATOR FAMILY DROP syntax has to include operand
types is that it lacks the full name/types of the referenced function.
Since getObjectDescription *does* provide those, it doesn't serve any
real purpose to repeat the information.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2011-01-11 19:03:37 Re: Allowing multiple concurrent base backups
Previous Message Magnus Hagander 2011-01-11 19:01:00 Re: Allowing multiple concurrent base backups