Re: [GENERAL] literal limits in 8.3 - Mailing list pgsql-hackers

From Sam Mason
Subject Re: [GENERAL] literal limits in 8.3
Date
Msg-id 20081124201440.GB2459@frubble.xen.chris-lamb.co.uk
Whole thread Raw
In response to Re: [GENERAL] literal limits in 8.3  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Nov 24, 2008 at 02:46:45PM -0500, Tom Lane wrote:
> What it boils down to is lack of error checking in psql (not the
> backend).  Specifically, we fail to enlarge the output buffer for
> psqlscan.l, which causes appendBinaryPQExpBuffer to silently not insert
> the chunk it's currently being passed.

> This is sort of a PITA to fix :-(.  The easiest solution from the point
> of view of psql would be to have realloc failure just print "out of
> memory" and exit(1), but pqexpbuffer.c is part of libpq and so it's not
> too reasonable for it to do that.  And we have also got to think about
> the prospect of similarly non-random lossage in other uses of
> PQexpbuffer, anyhow.
> 
> The least API-damaging solution I can think of is to add an error
> indicator flag to PQexpbuffer, comparable to ferror() on stdio files.
> Callers would have to check this after loading up a PQexpbuffer if
> they wanted to be sure there was no memory overrun.  But that seems
> pretty fragile, and it wouldn't be back-patchable.

Not much of a better idea; but from a correctness point of view an
option could be to have appendBinaryPQExpBuffer() abort if it runs out
of space and export an alternative function that allows the error to
propagate instead of aborting.

Not sure if that's allowed though; is there a link to the project's
guidelines for ABI compatibility?

 Sam


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] literal limits in 8.3
Next
From: Peter Eisentraut
Date:
Subject: Re: WIP: default values for function parameters