pgsql: Improve internationalization of messages involving type names

Alvaro,

* Alvaro Herrera (alvherre@alvh.no-ip.org) wrote:

Improve internationalization of messages involving type names

Change the slightly different variations of the message
function FOO must return type BAR
to a single wording, removing the variability in type name so that they
all create a single translation entry; since the type name is not to be
translated, there's no point in it being part of the message anyway.

Also, change them all to use the same quoting convention, namely that
the function name is not to be quoted but the type name is. (I'm not
quite sure why this is so, but it's the clear majority.)

Some similar messages such as "encoding conversion function FOO must ..."
are also changed.

Buildfarm is pretty upset with this one, in particular:

http://git.postgresql.org/gitweb/?p=postgresql.git;a=blobdiff;f=src/backend/commands/event_trigger.c;h=3735d44ee9d0b89f35ca8e8fb00b1a8dbbaa6362;hp=3f52ad836b4a2be1d95047f0949607d8cbbb283d;hb=59a2111;hpb=559e7a0a6d4450c09825055e3d255d30ee869c67

Thanks!

Stephen

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

Also, change them all to use the same quoting convention, namely that
the function name is not to be quoted but the type name is. (I'm not
quite sure why this is so, but it's the clear majority.)

Actually, I think the general convention is to NOT quote type names
in error messages. Certainly that's so when using format_type_be()
to produce a name for a not-known-at-compile-time type. I would
argue that these messages should be written to look the same as if
format_type_be() had been used, and that would mean leaving off
the quotes.

regards, tom lane

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Tom Lane wrote:

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

Also, change them all to use the same quoting convention, namely that
the function name is not to be quoted but the type name is. (I'm not
quite sure why this is so, but it's the clear majority.)

Actually, I think the general convention is to NOT quote type names
in error messages. Certainly that's so when using format_type_be()
to produce a name for a not-known-at-compile-time type. I would
argue that these messages should be written to look the same as if
format_type_be() had been used, and that would mean leaving off
the quotes.

Ok, I'll change it.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Alvaro Herrera wrote:

Tom Lane wrote:

Actually, I think the general convention is to NOT quote type names
in error messages. Certainly that's so when using format_type_be()
to produce a name for a not-known-at-compile-time type. I would
argue that these messages should be written to look the same as if
format_type_be() had been used, and that would mean leaving off
the quotes.

Ok, I'll change it.

Done.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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.

regards, tom lane

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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 as
errmsg("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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers