On 10.10.2012 16:58, Tom Lane wrote:
> Hannu Krosing<hannu@2ndQuadrant.com> writes:
>> Is the lack of support of cstring in PLs just laziness/ovelook or is
>> there a good
>> reason why PL languages do not support cstring type arguments and return
>> values ?
>
> In general I don't think we should encourage the use of cstring as a
> user-level data type. The number of text-like types in the system is
> already enough to confuse users, and this one brings no redeeming social
> value to the party. Besides which, it has essentially no built-in
> operators, and I *don't* want to have to add a pile of them for it.
>
>> I'm currently adding this to pl/pythonu with an aim to prototype type io
>> functions for a new type.
>
> 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)
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. That would
make it clear to the PL how to deal with the datums.
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. Custom
datatypes are really powerful, but as soon as you have to write C code,
that raises the bar significantly. I/O functions written in, say,
PL/pgSQL would be an order of magnitude slower than ones written in C,
but for many applications it would be OK.
- Heikki
