Re: BUG #15511: Drop table error "invalid argument"
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: ertugrul9090@gmail.com, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, pgsql-bugs@lists.postgresql.org
Date: 2018-12-06T21:00:42Z
Lists: pgsql-bugs
On 2018-Dec-06, Tom Lane wrote: > In principle, we could write some Perl code that exactly matches what > snprintf.c thinks is valid input, but I think that keeping it in sync > would be a nightmare. The concept I had in mind was to make a variant > version of snprintf.c that just validates a format string, and can be > compared to snprintf.c by diff'ing. (Or, perhaps, sprinkle snprintf.c > with #ifdefs so that compiling it with the right -D flag produces what > we want; though that might look too ugly.) If you don't mind adding > a C compiler to the list of dependencies for pg-make-po, we could imagine > having it compile up such a program at startup and then apply it to > each catalog. I don't follow. Why don't we just compile snprintf.c as-is and another .c file with a function that invokes vsnprintf on each translated string on a .po file and prints an error if vsnprintf returns EINVAL? This code runs completely under our control, and we can install whatever tools are needed. We don't need a C compiler today, but installing one is trivial. Also, we already have postgres source trees for each PG version available. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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