2018-04-03 21:47:18 +08:00
|
|
|
#include "postgres.h"
|
|
|
|
|
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
2018-04-04 23:28:33 +08:00
|
|
|
#include <math.h>
|
|
|
|
|
2018-04-03 21:47:18 +08:00
|
|
|
#include "fmgr.h"
|
|
|
|
#include "plperl.h"
|
|
|
|
#include "utils/fmgrprotos.h"
|
2019-10-23 11:56:22 +08:00
|
|
|
#include "utils/jsonb.h"
|
2018-04-03 21:47:18 +08:00
|
|
|
|
|
|
|
PG_MODULE_MAGIC;
|
|
|
|
|
|
|
|
static SV *Jsonb_to_SV(JsonbContainer *jsonb);
|
|
|
|
static JsonbValue *SV_to_JsonbValue(SV *obj, JsonbParseState **ps, bool is_elem);
|
|
|
|
|
|
|
|
|
|
|
|
static SV *
|
|
|
|
JsonbValue_to_SV(JsonbValue *jbv)
|
|
|
|
{
|
|
|
|
dTHX;
|
|
|
|
|
|
|
|
switch (jbv->type)
|
|
|
|
{
|
|
|
|
case jbvBinary:
|
Fix excessive enreferencing in jsonb-to-plperl transform.
We want, say, 2 to be transformed as 2, not \\2 which is what the
original coding produced. Perl's standard seems to be to add an RV
wrapper only for hash and array SVs, so do it like that.
This was missed originally because the test cases only checked what came
out of a round trip back to SQL, and the strip-all-dereferences loop at
the top of SV_to_JsonbValue hides the extra refs from view. As a better
test, print the Perl value with Data::Dumper, like the hstore_plperlu
tests do. While we can't do that in the plperl test, only plperlu,
that should be good enough because this code is the same for both PLs.
But also add a simplistic test for extra REFs, which we can do in both.
That strip-all-dereferences behavior is now a bit dubious; it's unlike
what happens for other Perl-to-SQL conversions. However, the best
thing to do seems to be to leave it alone and make the other conversions
act similarly. That will be done separately.
Dagfinn Ilmari Mannsåker, adjusted a bit by me
Discussion: https://postgr.es/m/d8jlgbq66t9.fsf@dalvik.ping.uio.no
2018-06-19 02:31:42 +08:00
|
|
|
return Jsonb_to_SV(jbv->val.binary.data);
|
2018-04-03 21:47:18 +08:00
|
|
|
|
|
|
|
case jbvNumeric:
|
|
|
|
{
|
|
|
|
char *str = DatumGetCString(DirectFunctionCall1(numeric_out,
|
|
|
|
NumericGetDatum(jbv->val.numeric)));
|
|
|
|
SV *result = newSVnv(SvNV(cstr2sv(str)));
|
2018-04-27 02:47:16 +08:00
|
|
|
|
2018-04-03 21:47:18 +08:00
|
|
|
pfree(str);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
case jbvString:
|
|
|
|
{
|
|
|
|
char *str = pnstrdup(jbv->val.string.val,
|
|
|
|
jbv->val.string.len);
|
|
|
|
SV *result = cstr2sv(str);
|
2018-04-27 02:47:16 +08:00
|
|
|
|
2018-04-03 21:47:18 +08:00
|
|
|
pfree(str);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
case jbvBool:
|
|
|
|
return newSVnv(SvNV(jbv->val.boolean ? &PL_sv_yes : &PL_sv_no));
|
|
|
|
|
|
|
|
case jbvNull:
|
|
|
|
return newSV(0);
|
|
|
|
|
|
|
|
default:
|
|
|
|
elog(ERROR, "unexpected jsonb value type: %d", jbv->type);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static SV *
|
|
|
|
Jsonb_to_SV(JsonbContainer *jsonb)
|
|
|
|
{
|
|
|
|
dTHX;
|
|
|
|
JsonbValue v;
|
|
|
|
JsonbIterator *it;
|
|
|
|
JsonbIteratorToken r;
|
|
|
|
|
|
|
|
it = JsonbIteratorInit(jsonb);
|
|
|
|
r = JsonbIteratorNext(&it, &v, true);
|
|
|
|
|
|
|
|
switch (r)
|
|
|
|
{
|
|
|
|
case WJB_BEGIN_ARRAY:
|
|
|
|
if (v.val.array.rawScalar)
|
|
|
|
{
|
|
|
|
JsonbValue tmp;
|
|
|
|
|
|
|
|
if ((r = JsonbIteratorNext(&it, &v, true)) != WJB_ELEM ||
|
|
|
|
(r = JsonbIteratorNext(&it, &tmp, true)) != WJB_END_ARRAY ||
|
|
|
|
(r = JsonbIteratorNext(&it, &tmp, true)) != WJB_DONE)
|
|
|
|
elog(ERROR, "unexpected jsonb token: %d", r);
|
|
|
|
|
Fix excessive enreferencing in jsonb-to-plperl transform.
We want, say, 2 to be transformed as 2, not \\2 which is what the
original coding produced. Perl's standard seems to be to add an RV
wrapper only for hash and array SVs, so do it like that.
This was missed originally because the test cases only checked what came
out of a round trip back to SQL, and the strip-all-dereferences loop at
the top of SV_to_JsonbValue hides the extra refs from view. As a better
test, print the Perl value with Data::Dumper, like the hstore_plperlu
tests do. While we can't do that in the plperl test, only plperlu,
that should be good enough because this code is the same for both PLs.
But also add a simplistic test for extra REFs, which we can do in both.
That strip-all-dereferences behavior is now a bit dubious; it's unlike
what happens for other Perl-to-SQL conversions. However, the best
thing to do seems to be to leave it alone and make the other conversions
act similarly. That will be done separately.
Dagfinn Ilmari Mannsåker, adjusted a bit by me
Discussion: https://postgr.es/m/d8jlgbq66t9.fsf@dalvik.ping.uio.no
2018-06-19 02:31:42 +08:00
|
|
|
return JsonbValue_to_SV(&v);
|
2018-04-03 21:47:18 +08:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
AV *av = newAV();
|
|
|
|
|
|
|
|
while ((r = JsonbIteratorNext(&it, &v, true)) != WJB_DONE)
|
|
|
|
{
|
|
|
|
if (r == WJB_ELEM)
|
|
|
|
av_push(av, JsonbValue_to_SV(&v));
|
|
|
|
}
|
|
|
|
|
Fix excessive enreferencing in jsonb-to-plperl transform.
We want, say, 2 to be transformed as 2, not \\2 which is what the
original coding produced. Perl's standard seems to be to add an RV
wrapper only for hash and array SVs, so do it like that.
This was missed originally because the test cases only checked what came
out of a round trip back to SQL, and the strip-all-dereferences loop at
the top of SV_to_JsonbValue hides the extra refs from view. As a better
test, print the Perl value with Data::Dumper, like the hstore_plperlu
tests do. While we can't do that in the plperl test, only plperlu,
that should be good enough because this code is the same for both PLs.
But also add a simplistic test for extra REFs, which we can do in both.
That strip-all-dereferences behavior is now a bit dubious; it's unlike
what happens for other Perl-to-SQL conversions. However, the best
thing to do seems to be to leave it alone and make the other conversions
act similarly. That will be done separately.
Dagfinn Ilmari Mannsåker, adjusted a bit by me
Discussion: https://postgr.es/m/d8jlgbq66t9.fsf@dalvik.ping.uio.no
2018-06-19 02:31:42 +08:00
|
|
|
return newRV((SV *) av);
|
2018-04-03 21:47:18 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
case WJB_BEGIN_OBJECT:
|
|
|
|
{
|
|
|
|
HV *hv = newHV();
|
|
|
|
|
|
|
|
while ((r = JsonbIteratorNext(&it, &v, true)) != WJB_DONE)
|
|
|
|
{
|
|
|
|
if (r == WJB_KEY)
|
|
|
|
{
|
|
|
|
/* json key in v, json value in val */
|
|
|
|
JsonbValue val;
|
|
|
|
|
|
|
|
if (JsonbIteratorNext(&it, &val, true) == WJB_VALUE)
|
|
|
|
{
|
|
|
|
SV *value = JsonbValue_to_SV(&val);
|
|
|
|
|
|
|
|
(void) hv_store(hv,
|
|
|
|
v.val.string.val, v.val.string.len,
|
|
|
|
value, 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Fix excessive enreferencing in jsonb-to-plperl transform.
We want, say, 2 to be transformed as 2, not \\2 which is what the
original coding produced. Perl's standard seems to be to add an RV
wrapper only for hash and array SVs, so do it like that.
This was missed originally because the test cases only checked what came
out of a round trip back to SQL, and the strip-all-dereferences loop at
the top of SV_to_JsonbValue hides the extra refs from view. As a better
test, print the Perl value with Data::Dumper, like the hstore_plperlu
tests do. While we can't do that in the plperl test, only plperlu,
that should be good enough because this code is the same for both PLs.
But also add a simplistic test for extra REFs, which we can do in both.
That strip-all-dereferences behavior is now a bit dubious; it's unlike
what happens for other Perl-to-SQL conversions. However, the best
thing to do seems to be to leave it alone and make the other conversions
act similarly. That will be done separately.
Dagfinn Ilmari Mannsåker, adjusted a bit by me
Discussion: https://postgr.es/m/d8jlgbq66t9.fsf@dalvik.ping.uio.no
2018-06-19 02:31:42 +08:00
|
|
|
return newRV((SV *) hv);
|
2018-04-03 21:47:18 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
default:
|
|
|
|
elog(ERROR, "unexpected jsonb token: %d", r);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static JsonbValue *
|
|
|
|
AV_to_JsonbValue(AV *in, JsonbParseState **jsonb_state)
|
|
|
|
{
|
|
|
|
dTHX;
|
|
|
|
SSize_t pcount = av_len(in) + 1;
|
|
|
|
SSize_t i;
|
|
|
|
|
|
|
|
pushJsonbValue(jsonb_state, WJB_BEGIN_ARRAY, NULL);
|
|
|
|
|
|
|
|
for (i = 0; i < pcount; i++)
|
|
|
|
{
|
|
|
|
SV **value = av_fetch(in, i, FALSE);
|
|
|
|
|
|
|
|
if (value)
|
|
|
|
(void) SV_to_JsonbValue(*value, jsonb_state, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
return pushJsonbValue(jsonb_state, WJB_END_ARRAY, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
static JsonbValue *
|
|
|
|
HV_to_JsonbValue(HV *obj, JsonbParseState **jsonb_state)
|
|
|
|
{
|
|
|
|
dTHX;
|
|
|
|
JsonbValue key;
|
|
|
|
SV *val;
|
2018-04-04 02:47:26 +08:00
|
|
|
char *kstr;
|
|
|
|
I32 klen;
|
2018-04-03 21:47:18 +08:00
|
|
|
|
|
|
|
key.type = jbvString;
|
|
|
|
|
|
|
|
pushJsonbValue(jsonb_state, WJB_BEGIN_OBJECT, NULL);
|
|
|
|
|
|
|
|
(void) hv_iterinit(obj);
|
|
|
|
|
2018-04-04 02:47:26 +08:00
|
|
|
while ((val = hv_iternextsv(obj, &kstr, &klen)))
|
2018-04-03 21:47:18 +08:00
|
|
|
{
|
2018-04-04 02:47:26 +08:00
|
|
|
key.val.string.val = pnstrdup(kstr, klen);
|
|
|
|
key.val.string.len = klen;
|
2018-04-03 21:47:18 +08:00
|
|
|
pushJsonbValue(jsonb_state, WJB_KEY, &key);
|
|
|
|
(void) SV_to_JsonbValue(val, jsonb_state, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
return pushJsonbValue(jsonb_state, WJB_END_OBJECT, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
static JsonbValue *
|
|
|
|
SV_to_JsonbValue(SV *in, JsonbParseState **jsonb_state, bool is_elem)
|
|
|
|
{
|
|
|
|
dTHX;
|
|
|
|
JsonbValue out; /* result */
|
|
|
|
|
|
|
|
/* Dereference references recursively. */
|
|
|
|
while (SvROK(in))
|
|
|
|
in = SvRV(in);
|
|
|
|
|
|
|
|
switch (SvTYPE(in))
|
|
|
|
{
|
|
|
|
case SVt_PVAV:
|
|
|
|
return AV_to_JsonbValue((AV *) in, jsonb_state);
|
|
|
|
|
|
|
|
case SVt_PVHV:
|
|
|
|
return HV_to_JsonbValue((HV *) in, jsonb_state);
|
|
|
|
|
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
2018-04-04 23:28:33 +08:00
|
|
|
default:
|
2019-08-05 02:05:34 +08:00
|
|
|
if (!SvOK(in))
|
|
|
|
{
|
|
|
|
out.type = jbvNull;
|
|
|
|
}
|
|
|
|
else if (SvUOK(in))
|
2018-06-19 05:39:57 +08:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If UV is >=64 bits, we have no better way to make this
|
|
|
|
* happen than converting to text and back. Given the low
|
|
|
|
* usage of UV in Perl code, it's not clear it's worth working
|
|
|
|
* hard to provide alternate code paths.
|
|
|
|
*/
|
|
|
|
const char *strval = SvPV_nolen(in);
|
|
|
|
|
|
|
|
out.type = jbvNumeric;
|
|
|
|
out.val.numeric =
|
|
|
|
DatumGetNumeric(DirectFunctionCall3(numeric_in,
|
|
|
|
CStringGetDatum(strval),
|
|
|
|
ObjectIdGetDatum(InvalidOid),
|
|
|
|
Int32GetDatum(-1)));
|
|
|
|
}
|
|
|
|
else if (SvIOK(in))
|
2018-04-03 21:47:18 +08:00
|
|
|
{
|
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
2018-04-04 23:28:33 +08:00
|
|
|
IV ival = SvIV(in);
|
2018-04-03 21:47:18 +08:00
|
|
|
|
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
2018-04-04 23:28:33 +08:00
|
|
|
out.type = jbvNumeric;
|
2020-09-10 02:16:28 +08:00
|
|
|
out.val.numeric = int64_to_numeric(ival);
|
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
2018-04-04 23:28:33 +08:00
|
|
|
}
|
|
|
|
else if (SvNOK(in))
|
|
|
|
{
|
|
|
|
double nval = SvNV(in);
|
|
|
|
|
2018-05-01 00:28:45 +08:00
|
|
|
/*
|
|
|
|
* jsonb doesn't allow infinity or NaN (per JSON
|
|
|
|
* specification), but the numeric type that is used for the
|
2020-07-23 07:19:44 +08:00
|
|
|
* storage accepts those, so we have to reject them here
|
|
|
|
* explicitly.
|
2018-05-01 00:28:45 +08:00
|
|
|
*/
|
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
2018-04-04 23:28:33 +08:00
|
|
|
if (isinf(nval))
|
2018-04-03 21:47:18 +08:00
|
|
|
ereport(ERROR,
|
2018-05-01 00:28:45 +08:00
|
|
|
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
|
2020-01-31 00:32:04 +08:00
|
|
|
errmsg("cannot convert infinity to jsonb")));
|
2018-05-01 00:28:45 +08:00
|
|
|
if (isnan(nval))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
|
2020-01-31 00:32:04 +08:00
|
|
|
errmsg("cannot convert NaN to jsonb")));
|
2018-04-03 21:47:18 +08:00
|
|
|
|
|
|
|
out.type = jbvNumeric;
|
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
2018-04-04 23:28:33 +08:00
|
|
|
out.val.numeric =
|
|
|
|
DatumGetNumeric(DirectFunctionCall1(float8_numeric,
|
|
|
|
Float8GetDatum(nval)));
|
|
|
|
}
|
|
|
|
else if (SvPOK(in))
|
|
|
|
{
|
|
|
|
out.type = jbvString;
|
|
|
|
out.val.string.val = sv2cstr(in);
|
|
|
|
out.val.string.len = strlen(out.val.string.val);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* XXX It might be nice if we could include the Perl type in
|
|
|
|
* the error message.
|
|
|
|
*/
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
2020-01-31 00:32:04 +08:00
|
|
|
errmsg("cannot transform this Perl type to jsonb")));
|
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
2018-04-04 23:28:33 +08:00
|
|
|
return NULL;
|
2018-04-03 21:47:18 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Push result into 'jsonb_state' unless it is a raw scalar. */
|
|
|
|
return *jsonb_state
|
|
|
|
? pushJsonbValue(jsonb_state, is_elem ? WJB_ELEM : WJB_VALUE, &out)
|
|
|
|
: memcpy(palloc(sizeof(JsonbValue)), &out, sizeof(JsonbValue));
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
PG_FUNCTION_INFO_V1(jsonb_to_plperl);
|
|
|
|
|
|
|
|
Datum
|
|
|
|
jsonb_to_plperl(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
dTHX;
|
|
|
|
Jsonb *in = PG_GETARG_JSONB_P(0);
|
|
|
|
SV *sv = Jsonb_to_SV(&in->root);
|
|
|
|
|
Fix excessive enreferencing in jsonb-to-plperl transform.
We want, say, 2 to be transformed as 2, not \\2 which is what the
original coding produced. Perl's standard seems to be to add an RV
wrapper only for hash and array SVs, so do it like that.
This was missed originally because the test cases only checked what came
out of a round trip back to SQL, and the strip-all-dereferences loop at
the top of SV_to_JsonbValue hides the extra refs from view. As a better
test, print the Perl value with Data::Dumper, like the hstore_plperlu
tests do. While we can't do that in the plperl test, only plperlu,
that should be good enough because this code is the same for both PLs.
But also add a simplistic test for extra REFs, which we can do in both.
That strip-all-dereferences behavior is now a bit dubious; it's unlike
what happens for other Perl-to-SQL conversions. However, the best
thing to do seems to be to leave it alone and make the other conversions
act similarly. That will be done separately.
Dagfinn Ilmari Mannsåker, adjusted a bit by me
Discussion: https://postgr.es/m/d8jlgbq66t9.fsf@dalvik.ping.uio.no
2018-06-19 02:31:42 +08:00
|
|
|
return PointerGetDatum(sv);
|
2018-04-03 21:47:18 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
PG_FUNCTION_INFO_V1(plperl_to_jsonb);
|
|
|
|
|
|
|
|
Datum
|
|
|
|
plperl_to_jsonb(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
dTHX;
|
|
|
|
JsonbParseState *jsonb_state = NULL;
|
|
|
|
SV *in = (SV *) PG_GETARG_POINTER(0);
|
|
|
|
JsonbValue *out = SV_to_JsonbValue(in, &jsonb_state, true);
|
|
|
|
Jsonb *result = JsonbValueToJsonb(out);
|
|
|
|
|
|
|
|
PG_RETURN_JSONB_P(result);
|
|
|
|
}
|