Re: Is there a good reason why PL languages do not support cstring type arguments and return values ?

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