Moving to -hackers.
Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Alvaro Herrera wrote:
> >> Tom Lane wrote:
> >>> Actually, I think the general convention is to NOT quote type names
> >>> in error messages.
>
> >> Ok, I'll change it.
>
> > Done.
>
> Thanks. Should we make a push to get rid of hard-wired type names in
> other messages? There's still quite a few "invalid input syntax for ..."
> instances that could be whacked until they all share the same translatable
> message.
Ah, I hadn't noticed those precisely because they lack the quotes ... I
grepped for 'type \"%' and found a few matches but didn't seem
interesting enough since there's only one of each, such aserrmsg("constant of the type \"regrole\" cannot be used
here")
The 'invalid input syntax' are much more numerous. Also the "value XYZ
is out of range" messages. Both of those seem definitely worth fixing.
I also saw "value too long" for char/varchar but they're only two
distinct messages and fixing those would require printing the maxlen in
place before raising the message -- probably not worth the trouble.
I also found these while paging through grep results,
src/backend/utils/adt/json.c: errmsg("could not determine data type for argument 1")));
src/backend/utils/adt/json.c: errmsg("could not determine data type for argument 2")));
src/backend/utils/adt/json.c: errmsg("could not determine data type for argument %d",
which seem worth merging too.
If nobody opposes, I will fix those after feature freeze.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
