Re: BUG #15511: Drop table error "invalid argument"
От | Tom Lane |
---|---|
Тема | Re: BUG #15511: Drop table error "invalid argument" |
Дата | |
Msg-id | 30307.1544130494@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #15511: Drop table error "invalid argument" (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: BUG #15511: Drop table error "invalid argument"
|
Список | pgsql-bugs |
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > 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? Because figuring out what additional arguments go with a particular format string is pretty hard, and we can't just not do that, or snprintf will likely dump core. We need a lobotomized version that doesn't attempt to fetch any of the variable parameters. > 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. OK. I'd visualize only adding the test code to HEAD, and pulling it from there to use for all back branches. regards, tom lane
В списке pgsql-bugs по дате отправления: