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
|
Список | 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 по дате отправления: