On 10/10/2012 02:58 PM, Tom Lane wrote:
Hannu Krosing <ha...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
