On 10/10/2012 03:46 PM, Tom Lane wrote:
Hannu Krosing <ha...@krosing.net> writes:
On 10/10/2012 02:58 PM, Tom Lane wrote:
It's hard for me to see how you'd make the above work without
circularity, ie the PL manager would end up recursively calling itself
trying to construct or deconstruct the value.
Again, could you be a bit more specific.
If you try to write "foo_out(foo) returns cstring" in Python, the
first thing plpython will try to do is convert the argument value
to a Python object, which for a non-built-in type such as "foo" is
going to reduce to conversion to text,
This should still be solvable _inside_ pl/python handler with a little
hackery.
My request for "reasons not to do it" was more about things in
pl manager or postgresql itself.
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)
or wrapped into plpy specific RawPg(rawinput) object.
which will result in ...
you guessed it ... calling foo_out to convert the argument value
to text. Lather, rinse, repeat till stack overflow.
As I was mentioning to Heikki, it's possible that you could work around
that by somehow telling plpython to do the argument conversion as though
the argument were of some bit-compatible built-in type rather than foo.
But without some such type cheat you can't write an I/O function in a
PL, and it's not the cstring end of it that's the problem.
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
