Missing library files??

Started by Tony Griffiths(RA)over 23 years ago7 messages
#1Tony Griffiths(RA)
griffitt@cs.man.ac.uk

Hi,
I've mailed this previously to the novice list, but got no response, so
hopefully this is more the appropriate place.

I'm trying to invoke the DirectFunctionCall1function as follows:

BOX* __tmp;
Datum d = DirectFunctionCall1(box_in,
BoxPGetDatum(ret_bbox));
__tmp = DatumGetBoxP(d);

(where ret_bbox is a string representation of a box)

from some client side code, but get linker errors stating that:

-> undefined reference to `DirectFunctionCall1(unsigned long
(*)(FunctionCallInfoData*), unsigned long)'

--> undefined reference to `box_in(FunctionCallInfoData*)

Is this because I'm calling the function incorrectly, or because I'm
missing the library in which these functions reside?

Many thanks,

Tony

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Tony Griffiths(RA) (#1)
Re: Missing library files??

"Tony Griffiths(RA)" <griffitt@cs.man.ac.uk> writes:

I'm trying to invoke the DirectFunctionCall1function as follows:
...
from some client side code, but get linker errors stating that:

-> undefined reference to `DirectFunctionCall1(unsigned long
(*)(FunctionCallInfoData*), unsigned long)'

Is this because I'm calling the function incorrectly, or because I'm
missing the library in which these functions reside?

There *is* no "library in which those functions reside". They are
internal to the server and are not designed to be included in
client-side code.

regards, tom lane

#3Tony Griffiths(RA)
griffitt@cs.man.ac.uk
In reply to: Tony Griffiths(RA) (#1)
Re: Missing library files??

Tom Lane wrote:

"Tony Griffiths(RA)" <griffitt@cs.man.ac.uk> writes:

I'm trying to invoke the DirectFunctionCall1function as follows:
...
from some client side code, but get linker errors stating that:

-> undefined reference to `DirectFunctionCall1(unsigned long
(*)(FunctionCallInfoData*), unsigned long)'

Is this because I'm calling the function incorrectly, or because I'm
missing the library in which these functions reside?

There *is* no "library in which those functions reside". They are
internal to the server and are not designed to be included in
client-side code.

Fair enough - that's what I half expected. I'm wanting to write some
embedded sql that selects a box attribute from a relation - is there any
direct way of retrieving a BOX typed value from the select without
having to go through decoding the retrieved string. I know I can do this
using a binary cursor, but this means moving from embedded sql.

Thanks,

Tony

Show quoted text

regards, tom lane

#4Tony Griffiths(RA)
griffitt@cs.man.ac.uk
In reply to: Tony Griffiths(RA) (#3)
Re: Missing library files??

Gavin Sherry wrote:

On Wed, 19 Jun 2002, Tom Lane wrote:

"Tony Griffiths(RA)" <griffitt@cs.man.ac.uk> writes:

I'm trying to invoke the DirectFunctionCall1function as follows:
...
from some client side code, but get linker errors stating that:

-> undefined reference to `DirectFunctionCall1(unsigned long
(*)(FunctionCallInfoData*), unsigned long)'

Is this because I'm calling the function incorrectly, or because I'm
missing the library in which these functions reside?

There *is* no "library in which those functions reside". They are
internal to the server and are not designed to be included in
client-side code.

You can access this function using the Fast Path Interface. See the libpq
documentation. However, I am unsure why you would want to get access to
this function on the client side.

I'm retrieving a box value via embedded sql, and wanted to use the
box_in method to decode the retrieved string - unless there's a direct
way of retrieving into a variable of the C type BOX??

Show quoted text

Gavin

#5Gavin Sherry
swm@linuxworld.com.au
In reply to: Tom Lane (#2)
Re: Missing library files??

On Wed, 19 Jun 2002, Tom Lane wrote:

"Tony Griffiths(RA)" <griffitt@cs.man.ac.uk> writes:

I'm trying to invoke the DirectFunctionCall1function as follows:
...
from some client side code, but get linker errors stating that:

-> undefined reference to `DirectFunctionCall1(unsigned long
(*)(FunctionCallInfoData*), unsigned long)'

Is this because I'm calling the function incorrectly, or because I'm
missing the library in which these functions reside?

There *is* no "library in which those functions reside". They are
internal to the server and are not designed to be included in
client-side code.

You can access this function using the Fast Path Interface. See the libpq
documentation. However, I am unsure why you would want to get access to
this function on the client side.

Gavin

#6Tom Lane
tgl@sss.pgh.pa.us
In reply to: Tony Griffiths(RA) (#3)
Re: Missing library files??

"Tony Griffiths(RA)" <griffitt@cs.man.ac.uk> writes:

Fair enough - that's what I half expected. I'm wanting to write some
embedded sql that selects a box attribute from a relation - is there any
direct way of retrieving a BOX typed value from the select without
having to go through decoding the retrieved string. I know I can do this
using a binary cursor, but this means moving from embedded sql.

The binary representation of BOX wouldn't necessarily be the same on
client and server machines anyway (surely you don't want to wire in
an assumption that client and server are on the same kind of hardware).

I'd say bite the bullet and parse the ASCII string; it's hardly
difficult.

regards, tom lane

#7Tony Griffiths(RA)
griffitt@cs.man.ac.uk
In reply to: Tony Griffiths(RA) (#1)
Re: Missing library files??

Tom Lane wrote:

"Tony Griffiths(RA)" <griffitt@cs.man.ac.uk> writes:

Fair enough - that's what I half expected. I'm wanting to write some
embedded sql that selects a box attribute from a relation - is there any
direct way of retrieving a BOX typed value from the select without
having to go through decoding the retrieved string. I know I can do this
using a binary cursor, but this means moving from embedded sql.

The binary representation of BOX wouldn't necessarily be the same on
client and server machines anyway (surely you don't want to wire in
an assumption that client and server are on the same kind of hardware).

I'd say bite the bullet and parse the ASCII string; it's hardly
difficult.

True, but if you guys decide to change the structure of a box string
down the line then not too good for backwards compatibility. sscanf here
I come....

Show quoted text

regards, tom lane