Skip site navigation (1) Skip section navigation (2)

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

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-11 09:34:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> 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.

Do you want a crazy idea now? Yes, I do mean Yet Another One.

I'm thinking about what it would take to have a new PL/C language where
the backend would actually compile and link/load the C code at CREATE
FUNCTION time, using dynamic code generation techniques.

That would allow writing functions in C and not have to ship a binary
executable file on the system, which would solve a bunch of problems.
With that tool and this use case, you could simply ship inline your C
coded IO functions in the middle of the PL/pythonu extension, using the
exact same mechanisms.

In the more general view of our offerings, that would fix C coded
extensions for Hot Standby, for one thing.

Dimitri Fontaine     PostgreSQL : Expertise, Formation et Support

In response to


pgsql-hackers by date

Next:From: Amit KapilaDate: 2012-10-11 10:17:11
Subject: Re: BUG #7534: walreceiver takes long time to detect n/w breakdown
Previous:From: Sébastien LardièreDate: 2012-10-11 09:33:36
Subject: Re: Truncate if exists

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group