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
Subject: Re: BUG #15511: Drop table error "invalid argument"
In-reply-to: <20181206210042.6fu2tkbxy3vehwul@alvherre.pgsql>
References: <20181206210042.6fu2tkbxy3vehwul@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Thu, 06 Dec 2018 18:00:42 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <30306.1544130494.1@sss.pgh.pa.us>
Date: Thu, 06 Dec 2018 16:08:14 -0500
Message-ID: <30307.1544130494@sss.pgh.pa.us>
Precedence: bulk

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