Skip site navigation (1) Skip section navigation (2)

Re: Bug #533: BLOB (lo type) objects could not be restored

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: sth(at)hq(dot)bsbg(dot)net, pgsql-bugs(at)postgresql(dot)org
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug #533: BLOB (lo type) objects could not be restored
Date: 2001-12-10 07:38:57
Message-ID: 3C146691.32F2C4FE@tpf.co.jp (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
pgsql-bugs(at)postgresql(dot)org wrote:
> 
> Stefan Hadjistoytchev (sth(at)hq(dot)bsbg(dot)net) reports a bug with a severity of 1
> The lower the number the more severe it is.
> 
> Short Description
> BLOB (lo type) objects could not be restored
> 
> Long Description
> Hi :)
> 
> Problem appeared in POSTGRESQL 7.2b3 CVS distribution
> 
> After creating a table containing BLOB (lo type) column and filling it in an error occured restoring this table using "pg_restore":
> 
> ERROR:  Unable to identify an operator '=' for types 'oid' and 'lo'
>         You will have to retype this query using an explicit cast

pg_restore in 7.2 could handle the type lo defined in
contrib/lo but couldn't handle the type lo you created by
  CREATE TYPE lo (
    internallength=4,  externallength=10,
    input=int4in, output=int4out,
    default='',  passedbyvalue
  );
The type is incomplete and hard to handle in pg_restore.

> Using Postgres 7.1.3 - there is no such error :(,

pg_restore in 7.1.x couldn't restore large objects
of type lo properly though it doesn't cause any error.

One way I can think of is to create the type lo in
contrib/lo in advance of pg_restore and ignore 
the 'create type lo ..' commands in pg_restore but
it seems pretty unnatural for pg_restore.

Comments ?

I've worried about the use of type lo which has
been used only(?) in ODBC. It doesn't seem wrong
because PostgreSQL hasn't provided the proper
BLOB type. However I'm not sure now how to handle
large objects in ODBC in future.

Comments ?

regards,
Hiroshi Inoue

In response to

pgsql-hackers by date

Next:From: Christof PetigDate: 2001-12-10 08:21:40
Subject: Re: pg_dump: Sorted output, referential integrity
Previous:From: Thomas LockhartDate: 2001-12-10 05:03:07
Subject: Re: text -> time cast problem

pgsql-bugs by date

Next:From: pgsql-bugsDate: 2001-12-10 09:34:22
Subject: Bug #534: factorial function
Previous:From: Tom LaneDate: 2001-12-09 20:21:48
Subject: Re: Bug #532: backend crashes due to segmentation fault

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group