On 10/10/2012 04:34 PM, Tom Lane wrote:
Hannu Krosing <ha...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
