upstream/postgresql
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-03-12 21:54:00 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions
postgresql/src/interfaces/ecpg
History
Tom Lane 06c723447b Second try at fixing numeric data passed through an ECPG SQLDA. 
In commit ecfd55795, I removed sqlda.c's checks for ndigits != 0 on the
grounds that we should duplicate the state of the numeric value's digit
buffer even when all the digits are zeroes.  However, that still isn't
quite right, because another possible state of the digit buffer is
buf == digits == NULL (this occurs for a NaN).  As the code now stands,
it'll invoke memcpy with a NULL source address and zero bytecount,
which we know a few platforms crash on.  Hence, reinstate the no-copy
short-circuit, but make it test specifically for buf != NULL rather than
some other condition.  In hindsight, the ndigits test (added by commit
f2ae9f9c3) was almost certainly meant to fix the NaN case not the
all-zeroes case as the associated thread alleged.

As before, back-patch to all supported versions.

Discussion: https://postgr.es/m/1803D792815FC24D871C00D17AE95905C71161@g01jpexmbkw24
2018-11-14 11:27:47 -05:00
..
compatlib Build src/common files as a library with -fPIC. 2018-09-28 14:28:19 -04:00
ecpglib Second try at fixing numeric data passed through an ECPG SQLDA. 2018-11-14 11:27:47 -05:00
include Fix more wrong paths in header comments 2018-07-11 17:57:04 +03:00
pgtypeslib Const-ify a few more large static tables. 2018-10-17 15:32:47 -04:00
preproc Fix realfailN lexer rules to not make assumptions about input format. 2018-11-13 14:54:41 -05:00
test Second try at fixing numeric data passed through an ECPG SQLDA. 2018-11-14 11:27:47 -05:00
Makefile Fix parallel make risk with new check temp-install setup 2015-04-29 20:34:22 -04:00
README.dynSQL Fix whitespace issues found by git diff --check, add gitattributes 2013-11-10 14:48:29 -05:00

README.dynSQL 

src/interfaces/ecpg/README.dynSQL

descriptor statements have the following shortcomings

- input descriptors (USING DESCRIPTOR <name>) are not supported

  Reason: to fully support dynamic SQL the frontend/backend communication
          should change to recognize input parameters.
          Since this is not likely to happen in the near future and you
          can cover the same functionality with the existing infrastructure
          (using s[n]printf), I'll leave the work to someone else.