From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Don't like getObjectDescription results for pg_amop/pg_amproc |
Date: | 2019-08-14 23:07:45 |
Message-ID: | 31599.1565824065@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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_ops for 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2019-08-14 23:55:17 | Re: Add "password_protocol" connection parameter to libpq |
Previous Message | Alvaro Herrera | 2019-08-14 21:42:36 | Re: progress report for ANALYZE |