aboutsummaryrefslogtreecommitdiff
path: root/src/interfaces/ecpg/ecpglib/data.c
Commit message (Collapse)AuthorAge
* Revert "Tidy up locale thread safety in ECPG library."Peter Eisentraut2025-03-28
| | | | | | | | This reverts commit 8e993bff5326b00ced137c837fce7cd1e0ecae14. It causes various build failures on the buildfarm, to be investigated. Discussion: https://postgr.es/m/CWZBBRR6YA8D.8EHMDRGLCKCD%40neon.tech
* Tidy up locale thread safety in ECPG library.Peter Eisentraut2025-03-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove setlocale() and _configthreadlocal() as fallback strategy on systems that don't have uselocale(), where ECPG tries to control LC_NUMERIC formatting on input and output of floating point numbers. It was probably broken on some systems (NetBSD), and the code was also quite messy and complicated, with obsolete configure tests (Windows). It was also arguably broken, or at least had unstated environmental requirements, if pgtypeslib code was called directly. Instead, introduce PG_C_LOCALE to refer to the "C" locale as a locale_t value. It maps to the special constant LC_C_LOCALE when defined by libc (macOS, NetBSD), or otherwise uses a process-lifetime locale_t that is allocated on first use, just as ECPG previously did itself. The new replacement might be more widely useful. Then change the float parsing and printing code to pass that to _l() functions where appropriate. Unfortunately the portability of those functions is a bit complicated. First, many obvious and useful _l() functions are missing from POSIX, though most standard libraries define some of them anyway. Second, although the thread-safe save/restore technique can be used to replace the missing ones, Windows and NetBSD refused to implement standard uselocale(). They might have a point: "wide scope" uselocale() is hard to combine with other code and error-prone, especially in library code. Luckily they have the _l() functions we want so far anyway. So we have to be prepared for both ways of doing things: 1. In ECPG, use strtod_l() for parsing, and supply a port.h replacement using uselocale() over a limited scope if missing. 2. Inside our own snprintf.c, use three different approaches to format floats. For frontend code, call libc's snprintf_l(), or wrap libc's snprintf() in uselocale() if it's missing. For backend code, snprintf.c can keep assuming that the global locale's LC_NUMERIC is "C" and call libc's snprintf() without change, for now. (It might eventually be possible to call our in-tree Ryū routines to display floats in snprintf.c, given the C-locale-always remit of our in-tree snprintf(), but this patch doesn't risk changing anything that complicated.) Author: Thomas Munro <thomas.munro@gmail.com> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Tristan Partin <tristan@partin.io> Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://postgr.es/m/CWZBBRR6YA8D.8EHMDRGLCKCD%40neon.tech
* Pre-beta mechanical code beautification.Tom Lane2023-05-19
| | | | | | | | | | | | | | | Run pgindent, pgperltidy, and reformat-dat-files. This set of diffs is a bit larger than typical. We've updated to pg_bsd_indent 2.1.2, which properly indents variable declarations that have multi-line initialization expressions (the continuation lines are now indented one tab stop). We've also updated to perltidy version 20230309 and changed some of its settings, which reduces its desire to add whitespace to lines to make assignments etc. line up. Going forward, that should make for fewer random-seeming changes to existing code. Discussion: https://postgr.es/m/20230428092545.qfb3y5wcu4cm75ur@alvherre.pgsql
* ecpg: Fix handling of strings in ORACLE compat code with SQLDAMichael Paquier2023-04-18
| | | | | | | | | | | | | | | | | | | | When compiled with -C ORACLE, ecpg_get_data() had a one-off issue where it would incorrectly store the null terminator byte to str[-1] when varcharsize is 0, which is something that can happen when using SQLDA. This would eat 1 byte from the previous field stored, corrupting the results generated. All the callers of ecpg_get_data() estimate and allocate enough storage for the data received, and the fix of this commit relies on this assumption. Note that this maps to the case where no padding or truncation is required. This issue has been introduced by 3b7ab43 with the Oracle compatibility option, so backpatch down to v11. Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/20230410.173500.440060475837236886.horikyota.ntt@gmail.com Backpatch-through: 11
* Remove fallbacks for strtoll, strtoull.Thomas Munro2022-08-06
| | | | | | | | | | | | | | strtoll was backfilled with either __strtoll or strtoq on systems without strtoll. The last such system on the buildfarm was an ancient HP-UX animal. We don't support HP-UX anymore, so remove. On other systems strtoll was present, but did not have a declaration. The last known instance on the buildfarm was running an ancient OSX and shut down in 2019. Author: Andres Freund <andres@anarazel.de> Reviewed-by: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/20220804013546.h65najrzig764jar@awork3.anarazel.de
* Remove extraneous blank lines before block-closing bracesAlvaro Herrera2022-04-13
| | | | | | | | | These are useless and distracting. We wouldn't have written the code with them to begin with, so there's no reason to keep them. Author: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20220411020336.GB26620@telsasoft.com Discussion: https://postgr.es/m/attachment/133167/0016-Extraneous-blank-lines.patch
* revert removal of hex_decode() from ecpg from commit c3826f831eBruce Momjian2020-12-24
| | | | | | | | ecpglib on certain platforms can't handle the pg_log_fatal calls from libraries. This was reported by the buildfarm. It needs a refactoring and return value change if it is later removed. Backpatch-through: master
* move hex_decode() to /common so it can be called from frontendBruce Momjian2020-12-24
| | | | | | | This allows removal of a copy of hex_decode() from ecpg, and will be used by the soon-to-be added pg_alterckey command. Backpatch-through: master
* Fix handling of structure for bytea data type in ECPGMichael Paquier2020-07-27
| | | | | | | | | | | | | | Some code paths dedicated to bytea used the structure for varchar. This did not lead to any actual bugs, as bytea and varchar have the same definition, but it could become a trap if one of these definitions changes for a new feature or a bug fix. Issue introduced by 050710b. Author: Shenhao Wang Reviewed-by: Vignesh C, Michael Paquier Discussion: https://postgr.es/m/07ac7dee1efc44f99d7f53a074420177@G08CNEXMBPEKD06.g08.fujitsu.local Backpatch-through: 12
* Remove HAVE_LONG_LONG_INTPeter Eisentraut2019-11-07
| | | | | | | | | | The presence of long long int is now implied in the requirement for C99 and the configure check for the same. We keep the define hard-coded in ecpg_config.h for backward compatibility with ecpg-using user code. Discussion: https://www.postgresql.org/message-id/flat/5cdd6a2b-b2c7-c6f6-344c-a406d5c1a254%402ndquadrant.com
* Make the order of the header file includes consistent in non-backend modules.Amit Kapila2019-10-25
| | | | | | | | | | | | Similar to commit 7e735035f2, this commit makes the order of header file inclusion consistent for non-backend modules. In passing, fix the case where we were using angle brackets (<>) for the local module includes instead of quotes (""). Author: Vignesh C Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/CALDaNm2Sznv8RR6Ex-iJO6xAdsxgWhCoETkaYX=+9DW3q0QCfA@mail.gmail.com
* Add bytea datatype to ECPG.Michael Meskes2019-02-18
| | | | | | | | | | | | So far ECPG programs had to treat binary data for bytea column as 'char' type. But this meant converting from/to escaped format with PQunescapeBytea/ PQescapeBytea() and therefore forcing users to add unnecessary code and cost for the conversion in runtime. By adding a dedicated datatype for bytea most of this special handling is no longer needed. Author: Matsumura-san ("Matsumura, Ryo" <matsumura.ryo@jp.fujitsu.com>) Discussion: https://postgr.es/m/flat/03040DFF97E6E54E88D3BFEE5F5480F737A141F9@G01JPEXMBYT04
* Rename ecpg's various "extern.h" files to have distinct names.Tom Lane2018-12-01
| | | | | | | | | | | This should reduce confusion, and in particular make it safe to copy typename.c into preproc/ and compile it there. This doesn't affect anything outside ecpg, and particularly not end users, because these files don't get installed; they just exist to share declarations among the .c files of each subdirectory. Discussion: https://postgr.es/m/31364.1543511708@sss.pgh.pa.us
* Rethink how to get float.h in old Windows API for isnan/isinfAlvaro Herrera2018-07-11
| | | | | | | | | | | | | | | | We include <float.h> in every place that needs isnan(), because MSVC used to require it. However, since MSVC 2013 that's no longer necessary (cf. commit cec8394b5ccd), so we can retire the inclusion to a version-specific stanza in win32_port.h, where it doesn't need to pollute random .c files. The header is of course still needed in a few places for other reasons. I (Álvaro) removed float.h from a few more files than in Emre's original patch. This doesn't break the build in my system, but we'll see what the buildfarm has to say about it all. Author: Emre Hasegeli Discussion: https://postgr.es/m/CAE2gYzyc0+5uG+Cd9-BSL7NKC8LSHLNg1Aq2=8ubjnUwut4_iw@mail.gmail.com
* Post-feature-freeze pgindent run.Tom Lane2018-04-26
| | | | Discussion: https://postgr.es/m/15719.1523984266@sss.pgh.pa.us
* Fix a boatload of typos in C comments.Tom Lane2018-04-01
| | | | | | Justin Pryzby Discussion: https://postgr.es/m/20180331105640.GK28454@telsasoft.com
* Add Oracle like handling of char arrays.Michael Meskes2018-03-14
| | | | | | | In some cases Oracle Pro*C handles char array differently than ECPG. This patch adds a Oracle compatibility mode to make ECPG behave like Pro*C. Patch by David Rader <davidr@openscg.com>
* Update typedefs.list and re-run pgindentRobert Haas2017-11-29
| | | | Discussion: http://postgr.es/m/CA+TgmoaA9=1RWKtBWpDaj+sF3Stgc8sHgf5z=KGtbjwPLQVDMA@mail.gmail.com
* Fix unportable usage of <ctype.h> functions.Tom Lane2017-11-07
| | | | | | | isdigit(), isspace(), etc are likely to give surprising results if passed a signed char. We should always cast the argument to unsigned char to avoid that. Error in commit 63d6b97fd, found by buildfarm member gaur. Back-patch to 9.3, like that commit.
* Improve error message for incorrect number inputs in libecpg.Michael Meskes2017-11-03
|
* Fix float parsing in ecpg INFORMIX mode.Michael Meskes2017-11-02
|
* Make sure ecpglib does accepts digits behind decimal point even for integers inMichael Meskes2017-11-01
| | | | | | Informix mode. Spotted and fixed by 高增琦 <pgf00a@gmail.com>
* Remove unnecessary parentheses in return statementsPeter Eisentraut2017-09-05
| | | | | | | | The parenthesized style has only been used in a few modules. Change that to use the style that is predominant across the whole tree. Reviewed-by: Michael Paquier <michael.paquier@gmail.com> Reviewed-by: Ryan Murphy <ryanfmurphy@gmail.com>
* Phase 3 of pgindent updates.Tom Lane2017-06-21
| | | | | | | | | | | | | | | | | | | | | | | | | Don't move parenthesized lines to the left, even if that means they flow past the right margin. By default, BSD indent lines up statement continuation lines that are within parentheses so that they start just to the right of the preceding left parenthesis. However, traditionally, if that resulted in the continuation line extending to the right of the desired right margin, then indent would push it left just far enough to not overrun the margin, if it could do so without making the continuation line start to the left of the current statement indent. That makes for a weird mix of indentations unless one has been completely rigid about never violating the 80-column limit. This behavior has been pretty universally panned by Postgres developers. Hence, disable it with indent's new -lpl switch, so that parenthesized lines are always lined up with the preceding left paren. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
* Phase 2 of pgindent updates.Tom Lane2017-06-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
* Remove useless duplicate inclusions of system header files.Tom Lane2017-02-25
| | | | | | | | | | | | | | | | c.h #includes a number of core libc header files, such as <stdio.h>. There's no point in re-including these after having read postgres.h, postgres_fe.h, or c.h; so remove code that did so. While at it, also fix some places that were ignoring our standard pattern of "include postgres[_fe].h, then system header files, then other Postgres header files". While there's not any great magic in doing it that way rather than system headers last, it's silly to have just a few files deviating from the general pattern. (But I didn't attempt to enforce this globally, only in files I was touching anyway.) I'd be the first to say that this is mostly compulsive neatnik-ism, but over time it might save enough compile cycles to be useful.
* Fixed array checking code for "unsigned long long" datatypes in libecpg.Michael Meskes2016-08-01
|
* Let compiler handle size calculation of bool types.Michael Meskes2015-09-17
| | | | Back in the day this did not work, but modern compilers should handle it themselves.
* Check for out of memory when allocating sqlca.Michael Meskes2015-06-15
| | | | Patch by Michael Paquier
* pgindent run for 9.5Bruce Momjian2015-05-23
|
* Remove null-pointer checks that are not needed.Michael Meskes2015-02-25
| | | | | If a pointer is guaranteed to carry information there is no need to check for NULL again. Patch by Michael Paquier.
* Fixed array handling in ecpg.Michael Meskes2015-02-10
| | | | | | When ecpg was rewritten to the new protocol version not all variable types were corrected. This patch rewrites the code for these types to fix that. It also fixes the documentation to correctly tell the status of array handling.
* pgindent run for 9.4Bruce Momjian2014-05-06
| | | | | This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
* Fix handling of array of char pointers in ecpglib.Michael Meskes2014-05-06
| | | | | | | | | | When array of char * was used as target for a FETCH statement returning more than one row, it tried to store all the result in the first element. Instead it should dump array of char pointers with right offset, use the address instead of the value of the C variable while reading the array and treat such variable as char **, instead of char * for pointer arithmetic. Patch by Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
* ECPG: Fix offset to NULL/size indicator array.Michael Meskes2013-11-26
| | | | Patch by Boszormenyi Zoltan <zb@cybertec.at>
* Fixed test for array boundary.Michael Meskes2012-10-05
| | | | | | Instead of continuing if the next character is not an array boundary get_data() used to continue only on finding a boundary so it was not able to read any element after the first.
* Standardize treatment of strcmp() return valuePeter Eisentraut2011-12-27
| | | | | Always compare the return value to 0, don't use cute tricks like if (!strcmp(...)).
* Remove cvs keywords from all files.Magnus Hagander2010-09-20
|
* Replace self written 'long long int' configure test by standard ↵Michael Meskes2010-05-25
| | | | 'AC_TYPE_LONG_LONG_INT' macro call.
* Ecpg now accepts "long long" datatypes even if "long" is 64bit wide. This ↵Michael Meskes2010-05-20
| | | | used to cover the equally long "long long" type. This patch closes bug #5464.
* Insert a hack into get_float8_nan (both core and ecpg copies) to deal withTom Lane2010-02-27
| | | | | | | | | | the fact that NetBSD/mips is currently broken, as per buildfarm member pika. Also add regression tests to ensure that get_float8_nan and get_float4_nan are exercised even on platforms where they are not needed by float8in/float4in. Zoltán Böszörményi and Tom Lane
* pgindent run for 9.0Bruce Momjian2010-02-26
|
* Streamlined array handling code in libecpg a little bit, in the process ↵Michael Meskes2010-02-04
| | | | fixing yet another incorrect log output.
* Fixed NaN/Infinity problems in ECPG for float/double/numeric/decimal by ↵Michael Meskes2010-02-02
| | | | | | making it OS independant. Patch done by Zoltán Böszörményi.
* Redefine Datum as uintptr_t, instead of unsigned long.Tom Lane2009-12-31
| | | | | | | This is more in keeping with modern practice, and is a first step towards porting to Win64 (which has sizeof(pointer) > sizeof(long)). Tsutomu Yamada, Magnus Hagander, Tom Lane
* If no result is given NOTFOUND should be returned. Check for empty resultMichael Meskes2009-11-27
| | | | string too.
* Applied patch by Boszormenyi Zoltan <zb@cybertec.at> to fix memory leak in ↵Michael Meskes2009-10-01
| | | | decimal handling.
* Remove unused ecpg variable.Bruce Momjian2009-08-07
|
* Added STRING datatype for Informix compatibility mode. This work isMichael Meskes2009-08-07
| | | | based on a patch send in by Böszörményi Zoltán <zb@cybertec.at>.
* NLS cleanup in ecpglibPeter Eisentraut2009-01-15
| | | | | | | | | | | | | | | | | Replace leftover instances of _() by ecpg_gettext(), the latter being the correct way to refer to the library's message catalog, instead of the one of the program using the library. Drop NLS support for ecpg_log(), which is a debugging instrument similar to elog() in the backend. We cannot support NLS in the ecpg compatlib, because that requires ecpg_gettext, which is in ecpglib, which is not a dependency of compatlib. It doesn't seem worthwhile to worry about this, since the only translatable string is "out of memory", and gettext probably won't be able to do much without memory either. Adjust messages to project style.
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-07 20:51:40 +0000