On 10/10/2012 05:34 PM, Tom Lane wrote:
> Hannu Krosing <hannu@krosing.net> writes:
>> One way would be to check that we are in an any --> cstring
>> function - perhaps just by setting some static flag et entry and resetting
>> it at exit - and pass the original byte representation as "bytes" (or
>> string for py2.x)
> Totally aside from the ugliness of driving that off the *other* end
> being cstring, it seems quite insufficient to me.
Please find attached a patch, which solves the typeio function recursion
problem by simply testing if the function we are currently in is a type-io
function (fn_oid == argTypeStruct->typoutput ... )
This is definitely WIP, put here just to verify the approach is mostly sane.
Also there are not integrated tests in the patch or docs yet.
See attached test-pytypeio.sql for sample usage.
It is usable for simple cases, like non-toastable fixed length types
- both pass by value and pass py reference - and
non-toastable varlen types. It has no expicit support yet for any
more fancy things like toasting or new short varlen headers.
It also has the beginnings of support for type "internal" so that also
send and receive functions can be written in plpython.
Some of the work also went into accepting shell types so that you
actually can define typeio functions,
> For example, if the
> data type in question is toastable, you don't really want to leave the
> Python code with the problem of detoasting a toasted value.
The next think I'll do is to fashion my raw input/output functions for
toastable cases after bytea. Currently they are just tested for simple
"old postgresql varlen type".
> Even if
> it's just an int, your proposal saddles the Python code with enddianness
> problems.
This can also be seen as a feature, that is you _can_ encode the binary
exactly as you like. For example you have 4-byte strings encoded in
int4-sized pass-by value chunks. or 16 digit decimals encoded as 16
4-bit nibbles.
And endianness dead simple to do in pythons struct module, as
it's just one char prefix in format string.
> I think my suggestion of a way to pretend the argument or result is of
> some specified other type for conversion purposes is quite a lot superior.
> In the toastable-type case, referencing bytea would be enough to get the
> Python code out from under detoasting and length-word management.
Will look into it.
----
Hannu Krosing
