v8 has ever invented TypedArray, which maps JS array to fixed-length element memory, originally for canvas pixel support. We utilize it for bytea conversion and int/float array. In the array case, we had to annotate the type by domain as it's an external array type to JS, otherwise, we would loose the current flexibility around array conversion. Those annotation type names may be changed in the future. Also, it might be reasonable to introduce TypedArray such like in d8, in order for users to make their own fixed-length element array, but it will be a different story.
The feature is enabled only if make is given ENABLE_DEBUGGER_SUPPORT=1, because we are not sure how much of v8 installations are with debug enabled. Maybe it is safe to flip the flag to DISABLE_DEBUGGER_SUPPORT. On the other hand, with static build, we are sure we can support it.
Now the json type is built-in since 9.2, it is reasonable to convert the text representation to/from object. V8 doesn't expose JsonParser interface to C++ client, so we ended up extracting JSON.parse/stringify from the global context. There shouldn't be any performance gain over the user script calling the functions, but it is only for convenience. This breaks the existing script that calls JSON.parse/stringify.
Type 'make static' and it will download v8 source, builds it, and do static link. It is still by default, as I think the dependency download/build takes too long for people who expect a lightweight installation, especially around PGXN. Will see if people want it as default.
Per report #41.
Now we build them by default, it is reasonable to expose them in PGXN. Also bump the recommended PostgreSQL version.
Dialects are now built by default. A new option DISABLE_DIALECT=1 suppress to build dialects into the shared object.
Previously we chose different numbers as distribution version and extension number, but it was sometimes confusing. Hope one version is better than two.
In some circumstances, it is convenient to link v8 statically while we still build plv8 with dynamic linking by default. v8 supports both of dynamic and static links, and also two modes of snapshot on and snapshot off in the static library. It might be possible to find the mode by looking at the v8 directory, but it is wise to let users explicitly choose it to avoid to shoot in the foot. Also rethink V8DIR, which was not working well. Previous coding was not so nice as the default value was quite unportable. Now we have two different variables, V8_SRCDIR pointing to the v8 source directory, and V8_OUTDIR pointing to the v8 build output directory. By default without specifying them, the system will find the appropriate ones. We might want to introduce our own configure script, but for now we stay in Makefile which is still simpler than other solutions.
Ideally we want to have only one place for the version string, but parsing META.json is a bit challenging; at one time we had v8/d8 parsing META.json to pass this value to source file, but it turned out those utilities may not be available everywhere. Since this integrity matters only developers, we just check it if they are available. We may come up with a better solution to have it in one place in the future.
It seems not all the options in CFLAGS that are available in gcc cannot be used in g++. This time only -Wall is specified with new OPTFLAGS, hoping developer can pass their arguments on demand.
In the previous coding, we didn't actually inherit any flags from PGXS. One of the significant flag was -g, which sometimes made it difficult to debug the code.
It seems Array::Cast does not return an empty handle. We should check the type by IsArray().
In this case we go looking for the d8 command anyway.
Field names returned by SRFs much exactly match the expected values, both in number and content. This is consistent with the requirements of other PLs. A couple of additional regression tests are added to monitor this.
We check that the right number of attributes are returned. Still to do is checking that the names match one to one. (The infrastructure is there, I just need to brush the cobwebs off my C++ to write the actual name comparison test, and it's too late at night for me to do that now.)
Some installations (e.g. Fedora) install the command line JSON interpreter as d8.
The mechanism is based on the variable parameter hook available since 9.0. For 8.4, we still have to specify the parameter types. plan.execute, plan.cursor is also updated to make use of this. Change ValueGetDatum and InferredDatumType to lower_case functions, as they look safe and natural to use outside of C++ try block. plv8_param.cc is also a bit modified to reduce code complexity in plv8_func.cc. In 8.4, plv8_param_state is never used, but leaving it in the source makes more readable than hiding the definition completely.