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

RE: pg_dumplo, thanks :) (fwd)

From: Don Baccus <dhogaza(at)pacifier(dot)com>
To: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>, Peter Mount <petermount(at)it(dot)maidstone(dot)gov(dot)uk>
Cc: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org>
Subject: RE: pg_dumplo, thanks :) (fwd)
Date: 2000-04-06 17:45:40
Message-ID: 3.0.1.32.20000406104540.013ff6e0@mail.pacifier.com (view raw or flat)
Thread:
Lists: pgsql-hackers
At 06:42 PM 4/6/00 +0200, Karel Zak wrote:
>
>On Thu, 6 Apr 2000, Peter Mount wrote:
>
>> In the past I had thought of writing something similar as an example for
>> JDBC (dump the LO's into a zip file). The thing I couldn't fathom (and
>> now I'm saying this, it's probably a simple thing to do), was the
>> restore. How do you create an lo with a specific oid?
>
> Very good question. IMHO is not method (in standard API) how create LO with 
>a specific oid. The pg_dumplo during LO-dump import rewrite (UPDATE) your
old 
>oid in defined column. Yes, you must not use LO's oid as join key between 
>tables or save LO's oid to the others columns than you defined in pg_dumplo
>command line.
>
> The TOAST is deliverance from this limitation.

We could actually deliver ourselves from this limitation absent TOAST, if
we wanted, by using something other than the OID as the key for the created
LO item.  In fact, this is sorta what I did for my BLOB-ish AOLserver hack
for our web toolkit, but I don't use the actual lo code for a variety of
reasons.

But I looked at it pretty thoroughly...

Since TOAST's on the horizon, I didn't have any real motivation or interest
in working up a less restrictive lo implementation and don't think there's
any real reason to do so.  But, LO's dependence on OIDs is an implementation
artifact that's not at all necessary.



- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2000-04-06 17:54:11
Subject: Re: Book and TEMP vs. TEMPORARY
Previous:From: Don BaccusDate: 2000-04-06 17:33:11
Subject: Re: pg_dumplo, thanks :) (fwd)

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