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
- scan-results (text/plain)
- test-po-files.patch (text/x-diff) patch
... 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
-
Improve our response to invalid format strings, and detect more cases.
- d8e1de899c8e 11.2 landed
- d398119c19ef 9.6.12 landed
- d2b0b60e7193 12.0 landed
- a40ee75c1e2c 9.5.16 landed
- 6dc46f8ca83d 10.7 landed
- 3a691f8a25a8 9.4.21 landed