On 10/10/2012 04: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,
The cstring case seems trivial - you just have to omit the initial
conversion
to cstring that is happening now for most types and only do only the second
part which is the cstring_to_python or cstring_to_postgresql conversion
depending on if it is an input or output function.
> it seems quite insufficient to me. 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. Even if
> it's just an int, your proposal saddles the Python code with enddianness
> problems.
>
> 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.
Agreed, and it even seems that we can reuse current existing basetype
support present in CREATE TYPE and pg_proc. If not functionally then at
least for storing the equivalent type info.
> In the toastable-type case, referencing bytea would be enough to get the
> Python code out from under detoasting and length-word management. There
> might also be cases where the new type is really a skin over some
> built-in type, and you can leverage that type's I/O behavior to simplify
> what the Python code has to do.
>
> regards, tom lane
