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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: ertugrul9090@gmail.com, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, pgsql-bugs@lists.postgresql.org
Date: 2018-12-06T23:38:21Z
Lists: pgsql-bugs

Attachments

... so my preliminary result is that there's a *boatload* of "invalid"
format strings in our translation files, all of them apparently with
the extra-space disease.  See attached.

While it looks like every one of these is a typo, I'm beginning to
have second thoughts about the premise here.  Presumably, the reason
we've not noticed this issue before is that almost all non-Windows
platforms were using libc's printf, which is going to implement the
full set of POSIX-specified flags including space.  As of HEAD that
is no longer the case, because we use snprintf.c everywhere.  While
it might not be a problem for our own code if snprintf.c is a couple
of flags short of full POSIX, I'm worrying that third-party code
might be unhappy if *printf in the PG environment behaves oddly.

So maybe the best compromise is to upgrade snprintf.c.  I think it'd
only take a few more lines to implement the space flag per spec.
The other flags that we aren't implementing are '#' ("alternate form")
and "'" (thousands grouping).  For those, I'd be a bit inclined to accept
them but treat 'em as no-ops.  On the other hand, that still leaves
some daylight between us and POSIX, in the form of stuff like "long
double" support, and I still don't want to go near that.

Thoughts?

For the archives' sake, I attach the code I used for this.
I'm now thinking maybe we wouldn't commit it, though.

			regards, tom lane

Commits

  1. Improve our response to invalid format strings, and detect more cases.