On Thu, 18 Oct 2007 10:55:19 -0400
"Billow Gao" <billowgy@gmail.com> wrote:
> Is it possible to write a dynamic loaded C function as an UDP or TCP
server?
>
> What we want to do it is:
> Add a search function which send a UDP package to remote UDP server
> and then listen to an UDP port, waiting for the result.
> Ideally, we don't close the UDP server after the search query end.
> So we can reuse it for next search.
>
> Is it possible?

>Short answer: yes. Slightly longer answer: If you need to ask this
>quetion then you should really talk to someone about network
>programming but this is the wrong list.

Thanks for your reply.

I can write the network program.
But I am not 100% sure whether I can add the c-language function (
http://www.postgresql.org/docs/8.2/i...e/xfunc-c.html)
to PostgreSQL. The function will be dynamic loaded by PostgreSQL.
I want to know whether there are any limitation on the function I wrote.

for example:
If I want to write a function:

PG_FUNCTION_INFO_V1(c_talktoremoteudp);


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.

Anyway, I guess that it can be done. I will write a simple function to test
it.

Ying


>If you are asking if PostgreSQL already does UDP then the answer is
>no. You need to write a server program that talks UDP in one direction
>and TCP to PostgreSQL in the other direction. Watch out for security
>issues.

On Thu, 18 Oct 2007 11:24:24 -0400
"Billow Gao" <billowgy@gmail.com> wrote:
> I can write the network program.
> But I am not 100% sure whether I can add the c-language function (
> http://www.postgresql.org/docs/8.2/i...e/xfunc-c.html)
> to PostgreSQL. The function will be dynamic loaded by PostgreSQL.
> I want to know whether there are any limitation on the function I wrote.
>
> for example:
> If I want to write a function:
>
> PG_FUNCTION_INFO_V1(c_talktoremoteudp);
>
>
> 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?

--
D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

"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

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Thanks. This is what I want to know :-)

Regards,

Billow

>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.



On 10/18/07, D'Arcy J.M. Cain <darcy@druid.net> wrote:
>
> On Thu, 18 Oct 2007 11:24:24 -0400
> "Billow Gao" <billowgy@gmail.com> wrote:
> > I can write the network program.
> > But I am not 100% sure whether I can add the c-language function (
> > http://www.postgresql.org/docs/8.2/i...e/xfunc-c.html)
> > to PostgreSQL. The function will be dynamic loaded by PostgreSQL.
> > I want to know whether there are any limitation on the function I wrote.
> >
> > for example:
> > If I want to write a function:
> >
> > PG_FUNCTION_INFO_V1(c_talktoremoteudp);
> >
> >
> > 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?
>
> --
> D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves
> http://www.druid.net/darcy/ | and a sheep voting on
> +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

On Thursday 18 October 2007 12:27:59 Billow Gao wrote:
> Thanks.* This is what I want to know :-)
>
> Regards,
>
> Billow
>
> >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.

> On 10/18/07, D'Arcy J.M. Cain <darcy@druid.net> wrote:
> On Thu, 18 Oct 2007 11:24:24 -0400
>
> "Billow Gao" <billowgy@gmail.com> wrote:
> > I can write the network program.
> > ...

Oh my. The worst kind of top-poster: the kind that copies *your* reply from
the bottom to the top and top-posts above that.

Shudder...



jan

--
--------------------------------------------------------------
Jan de Visser * * * * * * * * * * jdevisser@digitalfairway.com

* * * * * * * * Baruk Khazad! Khazad ai-menu!
--------------------------------------------------------------

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate