pgsql: MSVC 2012+: Permit linking to 32-bit, MinGW-built libraries.
MSVC 2012+: Permit linking to 32-bit, MinGW-built libraries. Notably, this permits linking to the 32-bit Perl binaries advertised on perl.org, namely Strawberry Perl and ActivePerl. This has a side effect of permitting linking to binaries built with obsolete MSVC versions. By default, MSVC 2012 and later require a "safe exception handler table" in each binary. MinGW-built, 32-bit DLLs lack the relevant exception handler metadata, so linking to them failed with error LNK2026. Restore the semantics of MSVC 2010, which omits the table from a given binary if some linker input lacks metadata. This has no effect on 64-bit builds or on MSVC 2010 and earlier. Back-patch to 9.3 (all supported versions). Reported by Victor Wagner. Discussion: https://postgr.es/m/20160326154321.7754a...@wagner.wagner.home Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d78c3ca0ea1012d9c944bae981b13151e4f86dcb Modified Files -- src/tools/msvc/MSBuildProject.pm | 2 ++ 1 file changed, 2 insertions(+)
pgsql: MSVC 2012+: Permit linking to 32-bit, MinGW-built libraries.
MSVC 2012+: Permit linking to 32-bit, MinGW-built libraries. Notably, this permits linking to the 32-bit Perl binaries advertised on perl.org, namely Strawberry Perl and ActivePerl. This has a side effect of permitting linking to binaries built with obsolete MSVC versions. By default, MSVC 2012 and later require a "safe exception handler table" in each binary. MinGW-built, 32-bit DLLs lack the relevant exception handler metadata, so linking to them failed with error LNK2026. Restore the semantics of MSVC 2010, which omits the table from a given binary if some linker input lacks metadata. This has no effect on 64-bit builds or on MSVC 2010 and earlier. Back-patch to 9.3 (all supported versions). Reported by Victor Wagner. Discussion: https://postgr.es/m/20160326154321.7754a...@wagner.wagner.home Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7e0c574ee26ce0308b76166312788e909b555c23 Modified Files -- src/tools/msvc/MSBuildProject.pm | 2 ++ 1 file changed, 2 insertions(+)
pgsql: MSVC 2012+: Permit linking to 32-bit, MinGW-built libraries.
MSVC 2012+: Permit linking to 32-bit, MinGW-built libraries. Notably, this permits linking to the 32-bit Perl binaries advertised on perl.org, namely Strawberry Perl and ActivePerl. This has a side effect of permitting linking to binaries built with obsolete MSVC versions. By default, MSVC 2012 and later require a "safe exception handler table" in each binary. MinGW-built, 32-bit DLLs lack the relevant exception handler metadata, so linking to them failed with error LNK2026. Restore the semantics of MSVC 2010, which omits the table from a given binary if some linker input lacks metadata. This has no effect on 64-bit builds or on MSVC 2010 and earlier. Back-patch to 9.3 (all supported versions). Reported by Victor Wagner. Discussion: https://postgr.es/m/20160326154321.7754a...@wagner.wagner.home Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/470de6a24d37d630515c5112e1bebe03a742b2c8 Modified Files -- src/tools/msvc/MSBuildProject.pm | 2 ++ 1 file changed, 2 insertions(+)
pgsql: MSVC 2012+: Permit linking to 32-bit, MinGW-built libraries.
MSVC 2012+: Permit linking to 32-bit, MinGW-built libraries. Notably, this permits linking to the 32-bit Perl binaries advertised on perl.org, namely Strawberry Perl and ActivePerl. This has a side effect of permitting linking to binaries built with obsolete MSVC versions. By default, MSVC 2012 and later require a "safe exception handler table" in each binary. MinGW-built, 32-bit DLLs lack the relevant exception handler metadata, so linking to them failed with error LNK2026. Restore the semantics of MSVC 2010, which omits the table from a given binary if some linker input lacks metadata. This has no effect on 64-bit builds or on MSVC 2010 and earlier. Back-patch to 9.3 (all supported versions). Reported by Victor Wagner. Discussion: https://postgr.es/m/20160326154321.7754a...@wagner.wagner.home Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e2cc65050b0bad0b6b0e291f1d0bf1b44b2b1369 Modified Files -- src/tools/msvc/MSBuildProject.pm | 2 ++ 1 file changed, 2 insertions(+)
pgsql: MSVC 2012+: Permit linking to 32-bit, MinGW-built libraries.
MSVC 2012+: Permit linking to 32-bit, MinGW-built libraries. Notably, this permits linking to the 32-bit Perl binaries advertised on perl.org, namely Strawberry Perl and ActivePerl. This has a side effect of permitting linking to binaries built with obsolete MSVC versions. By default, MSVC 2012 and later require a "safe exception handler table" in each binary. MinGW-built, 32-bit DLLs lack the relevant exception handler metadata, so linking to them failed with error LNK2026. Restore the semantics of MSVC 2010, which omits the table from a given binary if some linker input lacks metadata. This has no effect on 64-bit builds or on MSVC 2010 and earlier. Back-patch to 9.3 (all supported versions). Reported by Victor Wagner. Discussion: https://postgr.es/m/20160326154321.7754a...@wagner.wagner.home Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/055532badd16b01f54951559139cb664c456cb8f Modified Files -- src/tools/msvc/MSBuildProject.pm | 2 ++ 1 file changed, 2 insertions(+)
pgsql: MSVC 2012+: Permit linking to 32-bit, MinGW-built libraries.
MSVC 2012+: Permit linking to 32-bit, MinGW-built libraries. Notably, this permits linking to the 32-bit Perl binaries advertised on perl.org, namely Strawberry Perl and ActivePerl. This has a side effect of permitting linking to binaries built with obsolete MSVC versions. By default, MSVC 2012 and later require a "safe exception handler table" in each binary. MinGW-built, 32-bit DLLs lack the relevant exception handler metadata, so linking to them failed with error LNK2026. Restore the semantics of MSVC 2010, which omits the table from a given binary if some linker input lacks metadata. This has no effect on 64-bit builds or on MSVC 2010 and earlier. Back-patch to 9.3 (all supported versions). Reported by Victor Wagner. Discussion: https://postgr.es/m/20160326154321.7754a...@wagner.wagner.home Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/70dc7ad584f50f1c02d4d4a67bdf77b378017fa9 Modified Files -- src/tools/msvc/MSBuildProject.pm | 2 ++ 1 file changed, 2 insertions(+)
pgsql: Fix typo
Fix typo Reported by Robins Tharakan Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d8f632caec3fcc5eece9d53d7510322f11489fe4 Modified Files -- src/backend/parser/parse_utilcmd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix regression test output
Fix regression test output Missed this in the last commit. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ce1468d02bdbbe3aa710463fa9faaf8cf865ad72 Modified Files -- src/test/regress/expected/identity.out | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix typo
Fix typo Reported by Robins Tharakan Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/22e71b3afb1c3bc994ba71a8c41784ddec53ceda Modified Files -- src/backend/parser/parse_utilcmd.c | 2 +- src/test/regress/expected/identity.out | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix plpgsql to reinitialize record variables at block re-entry.
Fix plpgsql to reinitialize record variables at block re-entry. If one exits and re-enters a DECLARE ... BEGIN ... END block within a single execution of a plpgsql function, perhaps due to a surrounding loop, the declared variables are supposed to get re-initialized to null (or whatever their initializer is). But this failed to happen for variables of type "record", because while exec_stmt_block() expected such variables to be included in the block's initvarnos list, plpgsql_add_initdatums() only adds DTYPE_VAR variables to that list. This bug appears to have been there since the aboriginal addition of plpgsql to our tree. Fix by teaching plpgsql_add_initdatums() to include DTYPE_REC variables as well. (We don't need to consider other DTYPEs because they don't represent separately-stored values.) I failed to resist the temptation to make some nearby cosmetic adjustments, too. No back-patch, because there have not been field complaints, and it seems possible that somewhere out there someone has code depending on the incorrect behavior. In any case this change would have no impact on correctly-written code. Discussion: https://postgr.es/m/22994.1512800...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/390d58135b22bc25229b524a60f69682182201d8 Modified Files -- src/pl/plpgsql/src/pl_comp.c | 12 +--- src/pl/plpgsql/src/pl_exec.c | 20 +--- src/pl/plpgsql/src/plpgsql.h | 4 ++-- src/test/regress/expected/plpgsql.out | 27 +++ src/test/regress/sql/plpgsql.sql | 21 + 5 files changed, 68 insertions(+), 16 deletions(-)
