One of the nice things about PLV8 is that it transparently converts many builtin types to the equivalent PLV8 type, with code that looks like this:
There is special handling for records and arrays which I improved some recently, but otherwise any type that's not in the list gets converted to a string. Unfortunately, there's no way I can see of transparently converting an hstore to a JS object, which would be the natural thing to do. I have been wracking my brain without success to come up with a good way to do it. Part of the trouble is that the hstore module might not be installed at all, and if it is we don't know what Oid the type will have, nor where its functions are - in fact we can assume very little about it.
Hstore is a sufficiently useful (and widely used) type that I think we need to get either it or something better (possibly a JSON type, which unlike hstore need not be flat) into the core. The trail seems to have gone a bit cold on getting a JSON type, which is rather a pity, too.
switch (type->typid) { case OIDOID: return Uint32::New(DatumGetObjectId(datum)); case BOOLOID: return Boolean::New((bool) DatumGetBool(datum)); ...
There is special handling for records and arrays which I improved some recently, but otherwise any type that's not in the list gets converted to a string. Unfortunately, there's no way I can see of transparently converting an hstore to a JS object, which would be the natural thing to do. I have been wracking my brain without success to come up with a good way to do it. Part of the trouble is that the hstore module might not be installed at all, and if it is we don't know what Oid the type will have, nor where its functions are - in fact we can assume very little about it.
Hstore is a sufficiently useful (and widely used) type that I think we need to get either it or something better (possibly a JSON type, which unlike hstore need not be flat) into the core. The trail seems to have gone a bit cold on getting a JSON type, which is rather a pity, too.