Re: plpython crash on exception

Поиск
Список
Период
Сортировка
От Marko Kreen
Тема Re: plpython crash on exception
Дата
Msg-id e51f66da0711230053s26e309bct74dd73230cd893ec@mail.gmail.com
обсуждение исходный текст
Ответ на Re: plpython crash on exception  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: plpython crash on exception  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-patches
On 11/23/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Marko Kreen" <markokr@gmail.com> writes:
> > On 11/23/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Why?  I can't imagine any real use for it.  If you're thinking that
> >> it could provide a guide as to what to resize the buffer to, think
> >> again.
>
> >  If the output was truncated due to this limit then the return
> >  value is the number of characters (not including the trailing
> >  '\0') which would have been written to the final string if
> >  enough space had  been  available.
>
> > What problem do you see?
>
> The problem is that you are quoting from some particular system's
> manual, and not any kind of standard ... much less any standard that
> every platform we support follows.
>
> The real-world situation is that we are lucky to be able to tell
> vsnprintf success from failure at all :-(

Ah, ok.

I just saw the result used inside the function, so I thought
it is standard enough.


Actually, the meaning could be changed to *needmore
and compensated inside function:

 *needmore = (nprinted < buf->maxlen) ? buf->maxlen : nprinted + 1;

Then it would not matter if libc is conforming or not.

--
marko

В списке pgsql-patches по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: plpython crash on exception
Следующее
От: "Marko Kreen"
Дата:
Сообщение: Cleaner API for appendStringInfoVA