A little tricky to get right, but it works pretty well.
TODO: Do something with --monitor.
I initially wanted to avoid the exec() and just let Perl continue
running the rest of the script after fork(), but that runs into the
problem that perl really doesn't like it when you fork() in BEGIN.
I always keep messing up the aTHX_ and pTHX_ stuff because my system
perl isn't built with multiplicity, and I still haven't found a
satisfactory way of finding SV leaks. Valgrind can't track those :(
The tests are not as thourough as I would like. There's many ways to
mess this up.
I was initially planning to drop the ref on the prepared statement
immediately after executing the query, so that the $st object can be
kept around for introspection without consuming excess resources.
Unfortunately, PQcopyResult does not copy over information about bind
parameters, so we need another way to keep that information alive. I
ended up going for the simple solution: keep the ref on the prepared
statement...
This is simply magical. \o/
Vendored in khashl.h. I wouldn't have used it if this were the only
place where I'd need a custom hash table, but it should come in handy
for other tasks as well, especially when I get to implementing an LRU
for prepared statement caching.
(Can all be done with Perl HV's, but they're less efficient and more
cumbersome for these tasks)
+ refactor things a bit so that send & recv functions use the same
context struct, because the way they're setup is pretty much the same
for both. This also adds recursive type resolution for bind parameters.
These macros don't assume alignment and may be somewhat inefficient with
all that copying. I'm hoping GCC is able to optimize that crap somewhat.
Also the pg type receive functions can not, in fact, assume that their
input buffers are properly aligned. That won't necessarily be the case
for array elements.
NOW we're really getting to the part where this module is more awesome
than DBD::Pg.
(When I started working on this module I was expecting that the Postgres
binary protocol would send jsonb in a binary format as well and that I'd
be duplicating parts of the JSON parser/formatter to make that work, but
it turns out that Postgres just uses plain json for exchange. Saves me
some trouble, I guess)
I liked the Perl implementation of transactions, but managing state
between Perl and C is a bit cumbersome, so I've moved the whole thing
into C.
Also added a few statement configuration methods that currently don't do
anything yet.
Partly because some errors currently appeared to come from within FU::PG
itself, which is useless, and partly because it's common to wrap
database access methods, while that's exactly the kind of operation
where you *really* want to know where the error originated from.
(Source: too much time wasted debugging VNDB errors)
Was expecting the implementation of this to get overly complicated and
brittle, but using a counter-based cookie and doing parts of it in Perl
made it pretty easy actually. Pretty happy with how this turned out so
far.
TODO: documentation -.-
This shows I got some optimizing to do. I was expecting integer parsing
to be slower, though, but it looks like it can compete with JSON::XS's
specialized small-int parsing code anyway.
That completes the json_format() function for now. At least, it now does
everything I had planned for it.
Ended up at a bit over 300 LOC. That's larger than I had expected, but
still alright.
Going to need a way to pass arguments into the XS function anyway, so
might as well do the entire arg parsing step in XS while we're at it.
Provides a significant speedup for tiny inputs as well, but I don't find
that too interesting.
It works and can format all "plain" Perl data, but has a few known bugs
and limitations that still need to be worked out.
It's about 8x smaller than JSON::XS's encoder and *much* smaller than
Cpanel::JSON::XS, but this is just a first attempt, it'll grow.
