Обсуждение: Don't like getObjectDescription results for pg_amop/pg_amproc

I notice that for a pg_amop object, getObjectDescription does this:

                /*------
                   translator: %d is the operator strategy (a number), the
                   first two %s's are data type names, the third %s is the
                   description of the operator family, and the last %s is the
                   textual form of the operator with arguments.  */
                appendStringInfo(&buffer, _("operator %d (%s, %s) of %s: %s"),
                                 amopForm->amopstrategy,
                                 format_type_be(amopForm->amoplefttype),
                                 format_type_be(amopForm->amoprighttype),
                                 opfam.data,
                                 format_operator(amopForm->amopopr));

This might seem all right in isolation, but it produces completely horrid
results as soon as you plug it into some larger message.  For example,

contrib_regression=# alter operator family gin__int_ops using gin drop operator  8 (integer[],integer[]);
ERROR:  cannot drop operator 8 (integer[], integer[]) of operator family gin__int_ops for access method gin:
<@(integer[],integer[])because operator class gin__int_ops for access method gin requires it 
HINT:  You can drop operator class gin__int_ops for access method gin instead.

The colon seems like it ought to introduce a subsidiary sentence, but
it does not, and the reader is led off into the weeds trying to figure
out what connects to what.

I follow the point of trying to show the actual operator name, but
we gotta work harder on the presentation.  Perhaps this would work:

                appendStringInfo(&buffer, _("operator %d (%s, %s) (that is, %s) of %s"),
                                 amopForm->amopstrategy,
                                 format_type_be(amopForm->amoplefttype),
                                 format_type_be(amopForm->amoprighttype),
                                 format_operator(amopForm->amopopr),
                                 opfam.data);

leading to

ERROR:  cannot drop operator 8 (integer[], integer[]) (that is, <@(integer[],integer[])) of operator family
gin__int_opsfor access method gin because operator class gin__int_ops for access method gin requires it 

Likewise for pg_amproc entries, of course.

Or maybe we're just being too ambitious here and we should discard some of
this information.  I'm not really sure that the format_operator result
can be included without complete loss of intelligibility.

Thoughts?  I'm particularly unclear on how any of this might translate
into other languages, though I doubt that the current text is giving
good guidance to translators.

            regards, tom lane

On Thu, Aug 15, 2019 at 2:08 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Or maybe we're just being too ambitious here and we should discard some of
> this information.  I'm not really sure that the format_operator result
> can be included without complete loss of intelligibility.
>
> Thoughts?  I'm particularly unclear on how any of this might translate
> into other languages, though I doubt that the current text is giving
> good guidance to translators.

Can left and right types of pg_amop mismatch to those of pg_operatror?
 It probably could for domains, any* types or something.  But for
builtin opclasses they always match.

# select * from pg_amop amop join pg_operator op on op.oid =
amop.amopopr where amop.amoplefttype != op.oprleft or
amop.amoprighttype != op.oprright;
(0 rows)

Could we discard one pair of types from output?

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
> On Thu, Aug 15, 2019 at 2:08 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Or maybe we're just being too ambitious here and we should discard some of
>> this information.  I'm not really sure that the format_operator result
>> can be included without complete loss of intelligibility.

> Could we discard one pair of types from output?

Yeah, it would help to stop using format_operator and just print the
bare name of the operator.  (format_operator can actually make things
a whole lot worse than depicted in my example, because it may insist
on schema-qualification and double-quoting.)  In principle that could
be ambiguous ... but the pg_amop entry has already been identified fully,
and I don't think it needs to be part of the charter of this printout
to *also* identify the underlying operator with complete precision.

I'm still not sure how to cram the operator name into the output
without using a colon, though.

            regards, tom lane