Date: Thu, 6 Dec 2018 18:00:42 -0300
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
Subject: Re: BUG #15511: Drop table error "invalid argument"
Message-ID: <20181206210042.6fu2tkbxy3vehwul@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <29810.1544129712@sss.pgh.pa.us>
User-Agent: NeoMutt/20180716
Precedence: bulk

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