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

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

In response to

Responses

Browse pgsql-hackers by date

  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 ?