Re: pg_dump and LOs (another proposal) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_dump and LOs (another proposal)
Date
Msg-id 2375.962809764@sss.pgh.pa.us
Whole thread Raw
In response to pg_dump and LOs (another proposal)  (Philip Warner <pjw@rhyme.com.au>)
Responses Re: Re: pg_dump and LOs (another proposal)  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-hackers
Philip Warner <pjw@rhyme.com.au> writes:
> Having now flirted with recreating BLOBs (and even DBs) with matching OIDs,
> I find myself thinking it's a waste of effort for the moment. A modified
> version of the system used by Pavel Janik in pg_dumplo may be substantially
> more reliable than my previous proposal:

I like this a lot better than trying to restore the original OIDs.  For
one thing, the restore-original-OIDs idea cannot be made to work if what
we want to do is load additional tables into an existing database.

> For large databases, this system will rely heavily on lo_xref, so my main
> worries are:

> 1. How are temp tables stored? (eg. if in memory this is a problem -
> Dec/Rdb stores temp tables in memory).

> 2. Are there any limitation on indexes of temp tables (I seem to be able to
> create them at least - Dec/Rdb won't even let you do that).

No problem.  A temp table is a table, it's just got a unique name under
the hood.  (So do its indices, IIRC...)
        regards, tom lane


pgsql-hackers by date:

Previous
From: kuznet@ms2.inr.ac.ru
Date:
Subject: Re: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection
Next
From: Tim Perdue
Date:
Subject: Re: Article on MySQL vs. Postgres