Patch rejected. Sorry. Comment is:
The patch of very dubious portability and I'm not even convinced that
it'd provide a net performance improvement.
---
Marko Kreen wrote:
> Attached patch moves decision how much more roo
On 11/23/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > FWIW, SUS says that vsnprintf should act like snprintf and snprintf:
>
> I dunno where you're reading that, but it's certainly nowhere to be
> found in the version that I read:
>
> http://www.opengroup.
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> FWIW, SUS says that vsnprintf should act like snprintf and snprintf:
I dunno where you're reading that, but it's certainly nowhere to be
found in the version that I read:
http://www.opengroup.org/onlinepubs/007908799/xsh/vfprintf.html
On 11/23/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > Attached patch moves decision how much more room to allocate
> > from callers of appendStringInfoVA to inside the function,
> > where more info is available.
>
> This is by no stretch of the imagination
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> Attached patch moves decision how much more room to allocate
> from callers of appendStringInfoVA to inside the function,
> where more info is available.
This is by no stretch of the imagination "cleaner".
> On systems with broken vsnprintf() it falls b
