6 Commits (47c91b55991883322fdbc4495ce7fe6b2166e8fe)

Author	SHA1	Message	Date
Peter Eisentraut	651cb90941	Fix clashing function names between jsonb_plperl and jsonb_plperlu ... This prevented them from being installed at the same time. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>	8 years ago
Tom Lane	eac93e20af	Remove less-portable-than-believed test case. ... In commit 331b2369c I added a test to see what jsonb_plperl would do with a qr{} result. Turns out the answer is Perl version dependent. That fact doesn't bother me particularly, but coping with multiple result possibilities is way more work than this test seems worth. So remove it again. Discussion: https://postgr.es/m/E1f3MMJ-0006bf-B0@gemulon.postgresql.org	8 years ago
Tom Lane	331b2369c0	Fix platform and Perl-version dependencies in new jsonb_plperl code. ... Testing SvTYPE() directly is more fraught with problems than one might think, because depending on context Perl might be storing a scalar value in one of several forms, eg both numeric and string values. This resulted in Perl-version-dependent buildfarm test failures. Instead use the SvTYPE test only to distinguish non-scalar cases (AV, HV, NULL). Disambiguate scalars by testing SvIOK, SvNOK, then SvPOK. This creates a preference order for how we will resolve cases where the value is available in more than one form, which seems fine to me. Furthermore, because we're now dealing directly with a "double" value in the SvNOK case, we can get rid of an inadequate and unportable string-comparison test for infinities, and use isinf() instead. (We do need some additional #include and "-lm" infrastructure to use that in a contrib module, per prior experiences.) In passing, prevent the regression test results from depending on DROP CASCADE order; I've not seen that malfunction, but it's trouble waiting to happen. Discussion: https://postgr.es/m/E1f3MMJ-0006bf-B0@gemulon.postgresql.org	8 years ago
Tom Lane	dddfc4cb2e	Prevent accidental linking of system-supplied copies of libpq.so etc. ... We were being careless in some places about the order of -L switches in link command lines, such that -L switches referring to external directories could come before those referring to directories within the build tree. This made it possible to accidentally link a system-supplied library, for example /usr/lib/libpq.so, in place of the one built in the build tree. Hilarity ensued, the more so the older the system-supplied library is. To fix, break LDFLAGS into two parts, a sub-variable LDFLAGS_INTERNAL and the main LDFLAGS variable, both of which are "recursively expanded" so that they can be incrementally adjusted by different makefiles. Establish a policy that -L switches for directories in the build tree must always be added to LDFLAGS_INTERNAL, while -L switches for external directories must always be added to LDFLAGS. This is sufficient to ensure a safe search order. For simplicity, we typically also put -l switches for the respective libraries into those same variables. (Traditional make usage would have us put -l switches into LIBS, but cleaning that up is a project for another day, as there's no clear need for it.) This turns out to also require separating SHLIB_LINK into two variables, SHLIB_LINK and SHLIB_LINK_INTERNAL, with a similar rule about which switches go into which variable. And likewise for PG_LIBS. Although this change might appear to affect external users of pgxs.mk, I think it doesn't; they shouldn't have any need to touch the _INTERNAL variables. In passing, tweak src/common/Makefile so that the value of CPPFLAGS recorded in pg_config lacks "-DFRONTEND" and the recorded value of LDFLAGS lacks "-L../../../src/common". Both of those things are mistakes, apparently introduced during prior code rearrangements, as old versions of pg_config don't print them. In general we don't want anything that's specific to the src/common subdirectory to appear in those outputs. This is certainly a bug fix, but in view of the lack of field complaints, I'm unsure whether it's worth the risk of back-patching. In any case it seems wise to see what the buildfarm makes of it first. Discussion: https://postgr.es/m/25214.1522604295@sss.pgh.pa.us	8 years ago
Tom Lane	d4a4c3d5b4	Suppress compiler warning in new jsonb_plperl code. ... Some compilers are evidently pickier than others about whether Perl's I32 typedef should be considered equivalent to int. Dodge the problem by using a separate variable; the prior coding was a bit confusing anyway. Per buildfarm. Note this does nothing to fix the test failures due to SV_to_JsonbValue not covering enough variable types.	8 years ago
Peter Eisentraut	341e166180	Transforms for jsonb to PL/Perl ... Add a new contrib module jsonb_plperl that provides a transform between jsonb and PL/Perl. jsonb values are converted to appropriate Perl types such as arrays and hashes, and vice versa. Author: Anthony Bykov <a.bykov@postgrespro.ru> Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Reviewed-by: Aleksander Alekseev <a.alekseev@postgrespro.ru> Reviewed-by: Nikita Glukhov <n.gluhov@postgrespro.ru>	8 years ago