Re: Can a C function(server program) be a UDP or TCP server?

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net>
Cc: <billowgao(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Can a C function(server program) be a UDP or TCP server?
Date: 2007-10-18 16:22:47
Message-ID: 87ir54wfxk.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"D'Arcy J.M. Cain" <darcy(at)druid(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2007-10-18 16:23:47 Re: max_prepared_transactions default ... why 5?
Previous Message Gregory Stark 2007-10-18 16:07:20 Re: ts_rewrite aggregate API seems mighty ugly