From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | ertugrul9090(at)gmail(dot)com, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15511: Drop table error "invalid argument" |
Date: | 2018-12-06 21:00:42 |
Message-ID: | 20181206210042.6fu2tkbxy3vehwul@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-12-06 21:08:14 | Re: BUG #15511: Drop table error "invalid argument" |
Previous Message | Tom Lane | 2018-12-06 20:55:12 | Re: BUG #15511: Drop table error "invalid argument" |