On 10.10.2012 16:58, 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. 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
