Re: Bug in libpq implentation and omission in documentation? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bug in libpq implentation and omission in documentation?
Date
Msg-id 10884.1344436524@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bug in libpq implentation and omission in documentation?  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Bug in libpq implentation and omission in documentation?
List 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 by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: WIP fix proposal for bug #6123
Next
From: Tom Lane
Date:
Subject: Re: Possible bug in PostgreSQL 9.2 stable: TwoPhaseGetDummyBackendId()