Heikki Linnakangas <heikki.linnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers