From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Is there a good reason why PL languages do not support cstring type arguments and return values ? |
Date: | 2012-10-10 14:12:01 |
Message-ID: | 50758231.9000002@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10.10.2012 16:58, Tom Lane wrote:
> Hannu Krosing<hannu(at)2ndQuadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2012-10-10 14:26:51 | Re: Switching timeline over streaming replication |
Previous Message | Hannu Krosing | 2012-10-10 14:06:47 | Re: Is there a good reason why PL languages do not support cstring type arguments and return values ? |