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

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: Can a C function(server program) be a UDP or TCP server?
Дата
Msg-id 87ir54wfxk.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: Can a C function(server program) be a UDP or TCP server?  ("D'Arcy J.M. Cain" <darcy@druid.net>)
Список 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 по дате отправления:

Предыдущее
От: Gregory Stark
Дата:
Сообщение: Re: ts_rewrite aggregate API seems mighty ugly
Следующее
От: Gregory Stark
Дата:
Сообщение: Re: max_prepared_transactions default ... why 5?