Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> On 10.10.2012 16:58, Tom Lane wrote:
>> The PLs aren't meant to be usable as I/O functions. cstring is not the
>> problem there, it's access to the bit-level representation of the other
>> datatype. 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.
> I don't see the problem. The input function converts a text string to an
> opaque chunk of bytes, and the output function does the reverse. In a
> nutshell, an input function is like this:
> bytea mytype_in(text_representation text)
> and the output function is like this:
> text mytype_out(internal_representation bytea)
OK, that would work as long as you were willing to confine the feature
to types that are representation-equivalent to bytea. However, there's
a small problem, which is that I/O functions aren't actually *declared*
that way.
> In reality, of course, input functions take a cstring as argument, not
> text, and returns a "mytype" datum, not bytea. But I don't see why we
> couldn't allow the above signatures with text/bytea instead.
Because you'd totally destroy the tiny modicum of error checking that
exists now on whether CREATE TYPE's function arguments are sane.
> I've wanted to allow writing i/o functions in non-C languages for a long
> time as well, but never got around to do anything about it.
If we're going to do that, it should not be done by blowing a truck-size
hole in the semantics of I/O functions. I would prefer to see some
kind of wart added to the PL manager that says, in effect, "treat this
argument or result as bytea even though it's declared differently".
For one thing, that would scale easily to cases that are not
representation-compatible to bytea but something else (eg int4), so long
as the underlying language had an equivalent native type.
regards, tom lane
