Re: Looking for pure C function APIs for server extension: language handler and SPI - Mailing list pgsql-general

From John R Pierce
Subject Re: Looking for pure C function APIs for server extension: language handler and SPI
Date
Msg-id 56D65044.305@hogranch.com
Whole thread Raw
In response to Looking for pure C function APIs for server extension: language handler and SPI  (<david@andl.org>)
Responses Re: Looking for pure C function APIs for server extension: language handler and SPI  ("David Bennett" <davidb@pfxcorp.com>)
List pgsql-general
On 2/29/2016 3:55 PM, david@andl.org wrote:

What I need (to find or create) is a ‘pure’ C language API to support a Postgres server extension. By ‘pure’ I mean one that has no knowledge of Postgres internals and that could be called by a generic interface provided by some other tool that can support C language APIs.

 

The reason is that I’m looking to integrate a new language (Andl) into Postgres. To do that I need to find or create a ‘pure’ C-language API to interface with:

1.       The generic language call interface (pl_language_handler), which must handle conversion of Incoming language call parameters and outgoing language call return value.

1.       The backend query execution interface (SPI), which must handle conversion of outgoing query parameters and incoming query result values.



by "server extension" do you mean, you want to use Andi as a "PL/Andi" so you can write stored procedures i Andi callable within SQL queries?

or do you mean, you want your Andi programs to be able to execute normal postgresql queries as a regular client ? 


for the first, see
http://www.postgresql.org/docs/9.5/static/plhandler.html

for the latter, see
http://www.postgresql.org/docs/9.5/static/libpq.html



-- 
john r pierce, recycling bits in santa cruz

pgsql-general by date:

Previous
From: John McKown
Date:
Subject: Re: Looking for pure C function APIs for server extension: language handler and SPI
Next
From: Jeff Janes
Date:
Subject: Re: multicolumn index and setting effective_cache_size using human-readable-numbers