Message-ID: <5408CC0D.9060807@aklaver.com>
Date: Thu, 04 Sep 2014 13:31:09 -0700
From: Adrian Klaver <adrian.klaver@aklaver.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: David G Johnston <david.g.johnston@gmail.com>,
 pgsql-general@postgresql.org
Subject: Re: Re: [ADMIN] Cannot retrieve images inserted through
 VB and odbc, after a table reorganization.
References: <6909b219ecae4d41b431efdaf6c953a3@Exch2.invera.com>
 <CAFwQ8rd0Abfm=0j4Oq5D0hcRPBn=D7A-HJzSPJmDk=EgDMA9zQ@mail.gmail.com>
 <a45db4656040438eaf2034a8f5870b8d@Exch2.invera.com>
 <5407679B.2030906@aklaver.com>
 <aafcb3551e2c4dddb696ec4a6d6087e8@Exch2.invera.com>
 <54086B77.9090102@aklaver.com> <1409840147898-5817761.post@n5.nabble.com>
In-Reply-To: <1409840147898-5817761.post@n5.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-general-owner@postgresql.org

On 09/04/2014 07:15 AM, David G Johnston wrote:
> Adrian Klaver-4 wrote
>> On 09/04/2014 05:56 AM, Alanoly Andrews wrote:
>>> Hi Adrian,
>>>
>>> Thanks for that explanation of how the "relfilenode" changes after a
>>> table reorganization. It is not surprising that this happens because the
>>> table rows are being physically moved from one location to another. But
>>> such changes at the backend should be transparent to the end user. The VB
>>> code at the client side runs a simple sql like "select image from
>>> image_table where image_key=somevalue". There is no reference to
>>> postgres-specific internal variables like "oid" and "relfilenode". I do
>>> not know the inner workings of the postgres odbc driver; but I would be
>>> surprised if it works at the granularity of "oid" and "relfilenode" and
>>> that it would store the actual physical values of relfilenode (which
>>> would keep changing after every table reload, reorg etc.).
>>
>> In addition to what David mentioned, some more detail on what you are
>> calling a 'large object'.  In Postgres there is not really a 'large
>> object' type(though I am guilty of saying there is), instead there is a
>> way of working with large objects outside of the bytea type. Now in the
>> ODBC FAQ there is a recipe for creating a 'lo' type:
>>
>> http://psqlodbc.projects.pgfoundry.org/faq.html#4.4
>>
>> Is this what you are using?
>>
>> If not how are you working with the large objects?
>>
>> Also given that you are working with the Postgres ODBC driver, you might
>> want to break the cross post rule and ask this question on the psql-odbc
>> list:
>>
>> http://www.postgresql.org/list/pgsql-odbc/
>>
>> In any case your ODBC settings would be helpful.
>
> I suspect the OP is referring to the contrib module/extension:
>
> http://www.postgresql.org/docs/9.1/interactive/lo.html

Aaah, did not know that existed, thanks.

>
> David J.
>


-- 
Adrian Klaver
adrian.klaver@aklaver.com


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general