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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
Cc: 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 13:58:19
Message-ID: 25725.1349877499@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2012-10-10 14:02:53 Re: Improving the performance of psql tab completion
Previous Message Pavel Stehule 2012-10-10 13:56:46 Re: enhanced error fields