Re: Can a C function(server program) be a UDP or TCP server? - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Can a C function(server program) be a UDP or TCP server?
Date
Msg-id 87ir54wfxk.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Can a C function(server program) be a UDP or TCP server?  ("D'Arcy J.M. Cain" <darcy@druid.net>)
List pgsql-hackers
"D'Arcy J.M. Cain" <darcy@druid.net> writes:

> On Thu, 18 Oct 2007 11:24:24 -0400
>> And use it in PostgreSQL like:
>> 
>> =========================================
>> SELECT name, c_talktoremoteudp(emp, 1500) AS overpaid
>>     FROM emp
>>     WHERE name = 'Bill' OR name = 'Sam';
>> 
>> =========================================
>> The function c_talktoremoteudp will:
>> 1. send udp data to remote udp server
>> 2. monitor an udp port and wait for the reply
>> 3. return the data to the select query.
>
> I am confused.  The dynamic function resides in the server.  The query
> runs in the server.  Where is the "remoteness" in any of this?  Are you
> saying that there is a second server that is not PostgreSQL that uses
> UDP that you want to communicate with and merge info into the
> PostgreSQL server from?

Yeah, what he wants is to implement a function in Postgres which does
something like an LDAP or DNS lookup or something like that.

Sure you can do this. The only tricky bit is the thing you mentioned about
reusing the connection. You could always leave the connection in a safe state
and don't need to worry about cleaning it up then you could just store it in a
static variable which would be the simplest option.

If you want to use Postgres's facilities for allocating memory and cleaning it
up when no longer in use you can use some of the Postgres internal API for
memory contexts and resource owners. But I don't see any particular reason you
should need to worry about this stuff for something simple you're implementing
yourself.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: ts_rewrite aggregate API seems mighty ugly
Next
From: Gregory Stark
Date:
Subject: Re: max_prepared_transactions default ... why 5?