Re: [pgadmin-support] large object oid value not showing up in pgAdmin - Mailing list pgsql-novice

From Dave Page
Subject Re: [pgadmin-support] large object oid value not showing up in pgAdmin
Date
Msg-id 03AF4E498C591348A42FC93DEA9661B8259FE2@mail.vale-housing.co.uk
Whole thread Raw
List pgsql-novice
 
-----Original Message-----
From: Julie May [mailto:julie@ccorb.com]
Sent: 22 April 2003 21:54
To: Dave Page; pgadmin-support@postgresql.org
Cc: pgsql-novice@postgresql.org
Subject: Re: [pgadmin-support] large object oid value not showing up in pgAdmin

pgAdmin isn't affecting our ability to sync, we are just having the same problem with pgAdmin as we were with syncing. When I try to unlink the blob I get an error message because it doesn't recognize the oid value for the blob, instead it sees the /?|. I have spent most of the day reading about blobs, the lo datatype, and oids. I am now thoroughly confused and frustrated :( 
 
Sounds like it is an ODBC issue then, or your sync software is using the same MDAC code from Microsoft that pgAdmin does.
When I use lo_import with an oid column it seems to import the blob and show the oid of the blob but then I am not sure how to manage the blob so it does not leave unreferenced files behind or cause pgAdmin to crash. 
 
I know very little about lo's, but I do know you should use lo_import with lo columns, not oid's. The oid columns you see are merely how PostgreSQL actually stores the data.
 
To be honest though, I thought current 'best' practice was to use bytea columns. 
 
I'm cross posting this with the Novice list in case it is a more appropriate question for that list. 
 
Possibly. Certainly it's more an ODBC issue than pgAdmin, so I've moved it there. I'm sure someone there uses blobs in anger.
 
Wouldn't life be easier if Novices would quit trying to do advanced things with PostgreSql!?!
 
Yes, but far less interesting!
 
Regards, Dave.

pgsql-novice by date:

Previous
From: Fritz Lehmann-Grube
Date:
Subject: implicit lock in RULE ?
Next
From: radha.manohar@ndsu.nodak.edu
Date:
Subject: Re: Postgresql implementation