Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA92850 for ; Sun, 5 Dec 1999 18:34:35 -0500 (EST) (envelope-from tgl@sss.pgh.pa.us) Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id SAA07704; Sun, 5 Dec 1999 18:32:48 -0500 (EST) To: Charles Randle cc: pgsql-interfaces@postgresql.org Subject: Re: [INTERFACES] Problems with postgres V6.5.3 large objects In-reply-to: Your message of Sun, 05 Dec 1999 15:37:31 -0500 <384ACD0B.2491AFBE@cybervale.com> Date: Sun, 05 Dec 1999 18:32:48 -0500 Message-ID: <7702.944436768@sss.pgh.pa.us> From: Tom Lane Charles Randle writes: > 1) Whenever I try to open more than one large object within my class > (I'm using C++) The following message appears in the postgres backend > log-file & the application terminates . > ERROR: update_fp_info: cache lookup for function 1 failed This indicates that PQfn is being called with bad parameters (function ID 1; there's no such function). How are you accessing the large objects, exactly? > 2) I am thinking of using the libpq++ interface to access the large > objects , However from what I've seen each instance of the class would > create a new connection to the backend , from the same process ! Yes. This is a horribly brain-dead design; PgLargeObject needs to be rethought and rewritten. Probably PgLargeObject's constructor ought to take a reference to an existing connection object that it uses, rather than containing a connection object of its own. (For robustness, that would probably mean adding some kind of reference count to the connection objects...) > a) How expensive is this multiple connection option given that > many large objects may be in use at any one time ? Very. It's totally impractical if you are going to make heavy use of large objects. Most of the developers have not wanted to put much effort into large objects, since where we really want to go is to eliminate tuple size restrictions; once that happens large objects will be much less necessary. In the meantime, though, better code for PgLargeObject would be a nice contribution if you are interested. regards, tom lane