Horton

Thread

Commits

  1. Make messages mentioning type names more uniform

  2. Improve internationalization of messages involving type names

  3. psql tab-complete for CREATE/DROP ACCESS METHOD

  1. pgsql: Improve internationalization of messages involving type names

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2016-03-28T17:25:19Z

    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.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/59a2111b23f6ceec4c777d68e20c1027d3c57c6f

Modified Files
--------------
src/backend/commands/conversioncmds.c |  4 ++--
src/backend/commands/event_trigger.c  |  4 ++--
src/backend/commands/foreigncmds.c    |  4 ++--
src/backend/commands/operatorcmds.c   |  8 ++++----
src/backend/commands/proclang.c       |  8 ++++----
src/backend/commands/trigger.c        |  4 ++--
src/backend/commands/typecmds.c       | 37 ++++++++++++++++++-----------------
src/backend/parser/parse_clause.c     |  4 ++--
8 files changed, 37 insertions(+), 36 deletions(-)

  2. Re: pgsql: Improve internationalization of messages involving type names

    Stephen Frost <sfrost@snowman.net> — 2016-03-28T17:35:58Z

    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

  3. Re: pgsql: Improve internationalization of messages involving type names

    Tom Lane <tgl@sss.pgh.pa.us> — 2016-03-28T18:06:07Z

    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

  4. Re: pgsql: Improve internationalization of messages involving type names

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2016-03-30T21:43:54Z

    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

  5. Re: pgsql: Improve internationalization of messages involving type names

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2016-04-01T16:37:39Z

    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

  6. Re: pgsql: Improve internationalization of messages involving type names

    Tom Lane <tgl@sss.pgh.pa.us> — 2016-04-01T16:43:50Z

    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

  7. Re: [COMMITTERS] pgsql: Improve internationalization of messages involving type names

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2016-04-01T17:06:42Z

    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