mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-09-30 19:01:19 +02:00
c8e81afc60
It appears that we can no longer get away with using V0 call convention for bool-returning functions in newer versions of MSVC. The compiler seems to generate code that doesn't clear the higher-order bits of the result register, causing the bool result Datum to often read as "true" when "false" was intended. This is not very surprising, since the function thinks it's returning a bool-width result but fmgr_oldstyle assumes that V0 functions return "char *"; what's surprising is that that hack worked for so long on so many platforms. The only functions of this description in core+contrib are in contrib/seg, which we'd intentionally left mostly in V0 style to serve as a warning canary if V0 call convention breaks. We could imagine hacking things so that they're still V0 (we'd have to redeclare the bool-returning functions as returning some suitably wide integer type, like size_t, at the C level). But on the whole it seems better to convert 'em to V1. We can still leave the pointer- and int-returning functions in V0 style, so that the test coverage isn't gone entirely. Back-patch to 9.5, since our intention is to support VS2015 in 9.5 and later. There's no SQL-level change in the functions' behavior so back-patching should be safe enough. Discussion: <22094.1461273324@sss.pgh.pa.us> Michael Paquier, adjusted some by me |
||
|---|---|---|
| .. | ||
| adminpack | ||
| auth_delay | ||
| auto_explain | ||
| bloom | ||
| btree_gin | ||
| btree_gist | ||
| chkpass | ||
| citext | ||
| cube | ||
| dblink | ||
| dict_int | ||
| dict_xsyn | ||
| earthdistance | ||
| file_fdw | ||
| fuzzystrmatch | ||
| hstore | ||
| hstore_plperl | ||
| hstore_plpython | ||
| intagg | ||
| intarray | ||
| isn | ||
| lo | ||
| ltree | ||
| ltree_plpython | ||
| oid2name | ||
| pageinspect | ||
| passwordcheck | ||
| pg_buffercache | ||
| pg_freespacemap | ||
| pg_prewarm | ||
| pg_standby | ||
| pg_stat_statements | ||
| pg_trgm | ||
| pg_visibility | ||
| pgcrypto | ||
| pgrowlocks | ||
| pgstattuple | ||
| postgres_fdw | ||
| seg | ||
| sepgsql | ||
| spi | ||
| sslinfo | ||
| start-scripts | ||
| tablefunc | ||
| tcn | ||
| test_decoding | ||
| tsearch2 | ||
| tsm_system_rows | ||
| tsm_system_time | ||
| unaccent | ||
| uuid-ossp | ||
| vacuumlo | ||
| xml2 | ||
| contrib-global.mk | ||
| Makefile | ||
| README | ||
The PostgreSQL contrib tree
---------------------------
This subtree contains porting tools, analysis utilities, and plug-in
features that are not part of the core PostgreSQL system, mainly
because they address a limited audience or are too experimental to be
part of the main source tree. This does not preclude their
usefulness.
User documentation for each module appears in the main SGML
documentation.
When building from the source distribution, these modules are not
built automatically, unless you build the "world" target. You can
also build and install them all by running "make all" and "make
install" in this directory; or to build and install just one selected
module, do the same in that module's subdirectory.
Some directories supply new user-defined functions, operators, or
types. To make use of one of these modules, after you have installed
the code you need to register the new SQL objects in the database
system by executing a CREATE EXTENSION command. In a fresh database,
you can simply do
CREATE EXTENSION module_name;
See the PostgreSQL documentation for more information about this
procedure.