On 10/10/2012 02:58 PM, 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.
I don't understand where you see the problem here, python (and
I guess also most other pl-languages, possibly with the exception of
pl/pgsql) are well capable of accessing raw data.
> 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.
Recursion itself should not be a problem (except maybe for performance).
We already support calling pl* functions from inside other pl functions at
least via executing SELECT "plfunc()" .
>
> regards, tom lane
>
>
