Re: Bug in libpq implentation and omission in documentation?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Bug in libpq implentation and omission in documentation?
Дата
Msg-id 10884.1344436524@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Bug in libpq implentation and omission in documentation?  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: Bug in libpq implentation and omission in documentation?
Список pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> On 08.08.2012 12:36, Jim Vanns wrote:
>> I suggest then that the documentation is updated to reflect this? Anf
>> again, perhaps the 'int' for nParams should be an int16_t or short?

> I don't think we should change the function signature for this, but I 
> think a sanity check for "nParams < 32768" in libpq would be in order.

We *can't* change the function signature like that.  In the first place,
it would be an ABI break necessitating a bump in the .so major version
number, which would cause pain vastly out of proportion to the size of
this problem.  In the second place, if we did that, then if someone made
the same mistake and tried to pass umpteen thousand parameters to a
statement, the same truncation Jim is complaining of would still happen.
Only this way, it would happen silently inside the C function call
mechanism, such that neither the application nor libpq could detect the
problem.

A runtime check for too many parameters seems appropriate.  Assuming
that the error message it throws is well written, I don't think we need
to adjust the documentation.  There are many limitations that are not
spelled out in the docs, and adding every one of them would not amount
to a net improvement.  Considering that Jim is the first to try this in
however many years it's been since 7.4, I don't think that everybody
needs to read about this restriction while they're trying to absorb what
PQexecParams does.
        regards, tom lane


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

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: WIP fix proposal for bug #6123
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Possible bug in PostgreSQL 9.2 stable: TwoPhaseGetDummyBackendId()