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
