Hi!
So at that point the deed has been done.
The questions to ask:
1) Why the driver thinks it is being passed a large object in the first place?
Source data type was binary. It was mapped to oid for unknown reason.
2) Have there been any recent changes to code that passes through the ODBC driver that would account for 1)?
3) To help with 2), where is 'INSERT INTO report ( ... ) values (.. , '200936767'::lo, ... )" coming from?
My suspicion is that it is user initiated change.
This change was done by me. I added new reports from other database. Reports contain primary columns and import throws error about unknown lo type.
I removed bonary columns from import and after that import succeeds.
It looks like during this procces 3 rows were added to large object metadata table.
I used
select lo_unlink(oidnumber)
to remove them.
>If it is not and you suspect the ODBC driver then I would suggest bringing it up on the -odbc list:
>https://www.postgresql.org/list/pgsql-odbc/
I created binary data in client side creating FoxPro cursor
create cursor t ( t gen )
and used psqlodbc to insert this data:
create temp table test ( test bytea ) on commit drop;
insert into test values ( ?t.t );
This code throws exception
type "lo" does not exist
but each call adds new row to pg_largeobject_metadata table.
Odbc driver creates large object and adds lo cast. This large object remains even if transaction is rolled back due to unexisting lo type.
C7=0 (bytea as logvarbinary is false) is used in connection string.
Andrus.