Re: [GENERAL] literal limits in 8.3

Поиск
Список
Период
Сортировка
От Sam Mason
Тема Re: [GENERAL] literal limits in 8.3
Дата
Msg-id 20081124201440.GB2459@frubble.xen.chris-lamb.co.uk
обсуждение исходный текст
Ответ на Re: [GENERAL] literal limits in 8.3  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [GENERAL] literal limits in 8.3
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: WIP: default values for function parameters