Re: BUG #15511: Drop table error "invalid argument"

I wrote:
> =?utf-8?q?PG_Bug_reporting_form?= <noreply(at)postgresql(dot)org> writes:
>> Drop table error "HATA: vsnprintf failed: Invalid argument", error
>> code:"XX000" , PostgreSQL version..: "11.1"

> Hmm. Looking at snprintf.c, EINVAL could only be returned for an
> incorrect translated message (i.e. wrong use of %n$ notation),
> so it seems somebody fat-fingered a translation. We can infer
> that you're using the Turkish message set, but that doesn't help
> much to narrow down where the mistake is. What do you see if you
> do "set lc_messages = 'C'" and then repeat the failing command?

I poked at that to the extent of testing every string in 11.1's tr.po
against our implementation of snprintf, and what I find is this:

#. translator: second %s is, e.g., "table %s"
#: catalog/objectaddress.c:2694
#, c-format
msgid "column %s of %s"
msgstr "%2$s'nin %1$ sütunu"

This msgstr is legal according to POSIX, so it's not surprising that
GNU msgfmt doesn't complain about it; but our version of snprintf()
does, because space is not a valid flag character according to it.
So the bit "%1$ s" is valid to msgfmt but not to us.

Presumably, what failed for you was something along the lines of

regression=# create table foo (f1 int);
CREATE TABLE
regression=# create table bar (f1 foo);
CREATE TABLE
regression=# drop table foo;
ERROR: cannot drop table foo because other objects depend on it
DETAIL: column f1 of table bar depends on type foo
HINT: Use DROP ... CASCADE to drop the dependent objects too.

Conclusions:

(1) I don't know Turkish, but it seems clear that this is a typo
and the string ought to be

msgstr "%2$s'nin %1$s sütunu"

(2) It seems like a bad idea that pvsnprintf(), which must have
reported this message, knows full well that it's dealing with a
broken format string and yet doesn't print out that format string.
It would have taken much less work to find this problem if it had.

(3) I'm quite unwilling to try to make snprintf.c accept absolutely
everything that's in the POSIX spec, especially seeing that this
particular omission caught a mistake.

(4) However, that leaves us with a translation problem, because msgfmt
doesn't detect some things that we'll fail on at runtime. What shall
we do about that?

regards, tom lane