My product is a library on top of the libpq C Library. The product API
provides our users flexibility to run any SQL. The results of the
execution are processed generically based on the result schema returned
I can think of these use cases on the top of my head which would need to
distinguish oid from lo:
1. Fetching OID of a user defined type. It could be used for other
operations on the type, such as parameter binding, result field type
2. Querying system tables. Tables such as pg_class, pg_attribute, etc
return many fields which are of type OID.
3. Querying tableoid or oid columns of a user table.
In all the above cases, OIDs are to be returned as integers. OTOH, for
an lo object the object must be fetched and returned.
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Thursday, February 15, 2007 10:57 PM
To: Unmesh Churi
Subject: Re: [BUGS] BUG #3015: libpq: PQftype() on a lo type result
column returns Oid of type oid instead of Oid of type lo.
"Unmesh Churi" <churi(at)roguewave(dot)com> writes:
> Thanks Tom. I used to rely on the PQftype() to determine if the OIDs
> stored in that result field are pointing to large objects or not. If
> they are large objects, I used to fetch them using lo_* API.
> Now since PQftype() returns type oid for type lo columns, how will I
> identify if a result column contains large objects or not?
Do you need to identify that? What other use-case has your application
got for fetching OID columns?
regards, tom lane
In response to
pgsql-bugs by date
|Next:||From: Bruce Momjian||Date: 2007-02-17 03:11:36|
|Subject: Re: [BUGS] BUG #2996: to_char( timestamp, 'DD-Mon-YYYY
HH24:MI:SS.MS' ) reports .1000 ms|
|Previous:||From: Phil Frost||Date: 2007-02-16 21:59:38|
|Subject: Re: Segfaults and assertion failures with not too extraordinary views and queries |