Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 054FA633107; Tue, 17 Mar 2009 10:27:45 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 04004-01-5; Tue, 17 Mar 2009 10:27:32 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by mail.postgresql.org (Postfix) with ESMTP id 06D4B63259C; Tue, 17 Mar 2009 10:27:38 -0300 (ADT) Received: by wf-out-1314.google.com with SMTP id 23so3742011wfg.28 for ; Tue, 17 Mar 2009 06:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=5AaJBQ0Z6RWYNUtsSIwRVS28nnfeQfa2E8ih3OKpMJo=; b=W9zN5ufRsX+hLOJ87oshOuempglqN4X/g8Xps0Z9Q5K6/7LYMkxvEnlDVMwRvwY8lR /68ZbCbAcVZNhYVbIgzQ0kRp6fTJE7Hu59hdntRHKUR6xiSy8vUuN+DnDFsFdIM33UCo Q5AFL6h/BRdSAzTi8fNpwGhQQwaveQ/WCfJbY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cO8l2KHZglwGlFoG9vzadLvVlOzgvrN/b9u5TehuvmhNMLqiBv9yTv0z6vf/8Wwnjt OQ/kmk2rAWfcA/OHBZyBj8NuWPyqxHAohWQwXblNBIssVRLPuNFegFiSi/b2FO26frsJ zwQaw/rPfDxcrWkZnbHeVcu+PdavZOYp+dzNo= MIME-Version: 1.0 Received: by 10.115.59.4 with SMTP id m4mr4246876wak.204.1237296455658; Tue, 17 Mar 2009 06:27:35 -0700 (PDT) In-Reply-To: <6995.1237293785@sss.pgh.pa.us> References: <6995.1237293785@sss.pgh.pa.us> Date: Tue, 17 Mar 2009 18:57:35 +0530 Message-ID: Subject: Re: [GENERAL] different results for large objects From: c k To: Tom Lane Cc: pgsql-general@postgresql.org, pgsql-admin@postgresql.org Content-Type: multipart/alternative; boundary=00163649a743b8ae2e04655087a9 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.001 tagged_above=0 required=5 tests=HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 200903/187 X-Sequence-Number: 31687 --00163649a743b8ae2e04655087a9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yes, the problem is with PGAdmin and ODBC connection to MS access. The function (given is first mail) is giving same results i.e. only IDs not the actual data from PGAdmin and ODBC. But for following query PGAdmin gives again only IDs, but MS Access through ODBC gives the actual binary data. select docimages.* from docimages where docimages.accobjecttype=9 ORDER BY docimages.docimagename; So I think ODBc is making some magic here for showing large object data. If this is correct how can I retrieve the actual binary data from a function/single statement as above? Thanks, CPK On Tue, Mar 17, 2009 at 6:13 PM, Tom Lane wrote: > c k writes: > > I am getting correct results with following query i.e. binary objects as > > they are inserted. > > > select docimages.* from docimages where docimages.accobjecttype=9 ORDER > BY > > docimages.docimagename; > > > but when I created a function as follows, binary objects are not shown, > > There is no server-side behavior that would cause that query to show you > a large object's contents instead of its identifying number. I suppose > that you have some client-side code that does something magic when it > sees a result column of type "lo", and that for some reason this code > is not successfully recognizing the case where the column is coming out > of a function. Since you've shown us neither the troublesome query > nor the client-side code, it's hard to speculate further than that. > > regards, tom lane > --00163649a743b8ae2e04655087a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, the problem is with PGAdmin and ODBC connection to MS access.
The f= unction (given is first mail) is giving same results i.e. only IDs not the = actual data from PGAdmin and ODBC.
But for following query PGAdmin gives= again only IDs, but MS Access through ODBC gives the actual binary data.
select docimages.* from docimages where docimages.accobjecttype=3D9 ORDER B= Y docimages.docimagename;

So I think ODBc is making some magic here for showing large object data= . If this is correct how can I retrieve the actual binary data from a funct= ion/single statement as above?

Thanks,
CPK

On Tue, Mar 17, 2009 at 6:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

c k <s= hreeseva.learning@gmail.com> writes:
> I am getting correct results with following query i.e. binary objects = as
> they are inserted.

> select docimages.* from docimages where docimages.accobjecttype=3D9 OR= DER BY
> docimages.docimagename;

> but when I created a function as follows, binary objects are not shown= ,

There is no server-side behavior that would cause that query to show = you
a large object's contents instead of its identifying number. =A0I suppo= se
that you have some client-side code that does something magic when it
sees a result column of type "lo", and that for some reason this = code
is not successfully recognizing the case where the column is coming out
of a function. =A0Since you've shown us neither the troublesome query nor the client-side code, it's hard to speculate further than that.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regards, tom lane

--00163649a743b8ae2e04655087a9--