From: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [GENERAL] literal limits in 8.3 |
Date: | 2008-11-24 20:14:40 |
Message-ID: | 20081124201440.GB2459@frubble.xen.chris-lamb.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-11-24 20:58:23 | Re: literal limits in 8.3 |
Previous Message | Greg Sabino Mullane | 2008-11-24 20:08:00 | Re: literal limits in 8.3 |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-11-24 20:58:23 | Re: literal limits in 8.3 |
Previous Message | Greg Sabino Mullane | 2008-11-24 20:08:00 | Re: literal limits in 8.3 |