From: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: heap_create with OID? |
Date: | 2000-07-04 07:43:43 |
Message-ID: | 3.0.5.32.20000704174343.02546410@mail.rhyme.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At 02:57 4/07/00 -0400, Tom Lane wrote:
>Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
>> I am wondering if anyone can see an immediate problem in creating a
function:
>> heap_create_oid
>> which is just like heap_create, but takes an oid arg. This oid (assuming
>> it's free) would be used to create the object.
>
>How exactly do you propose to determine that the OID is free?
Based on the comments so far, I don't.
pg_dump already allows a 'with-oid' option for table dumping & loading, and
the way it gets around the problem is to save the max oid at dump time,
then set the max oid at restore time. I am only seeking a way of doing a
valid backup/restore which includes BLOBS; so even if I say to the user
that BLOBs can only be restored as part of a full restore, then I think
it's a lot better than the current system.
>There's no inherent problem in forcing a particular choice of OID;
>initdb does it on every run. The trick is to avoid a conflict of
>OID assignments.
OK. This is good news. The way pg_dump sets the max oid is:
CREATE TABLE pgdump_oid (dummy int4);
COPY pgdump_oid WITH OIDS FROM stdin;
1282249 0
\.
where 1282249 is the max oid you want to set.
It's pretty crude, but I assume effective. What would be very nice is if I
could 'reserve' the OIDs of the to-be-created BLOBS without having to
create rows/tables etc, and without affecting the max oid. But that is
probably pointless if a decent BLOB implementation is coming along.
>My own feeling is that the current LO setup is fundamentally flawed
You will get no disagreement from me.
>the right answer is
>to find a way to avoid that.
I'm reluctant to do too much in this area until the capabilities of TOAST
are sorted out...
ISTM that, even if a new BLOB architecture comes along, some kind of
migration utility will be needed.
Does this all sound reasonable?
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2000-07-04 07:46:35 | Re: [GENERAL] Re: [HACKERS] proposed improvements to PostgreSQL license |
Previous Message | Philip Warner | 2000-07-04 07:33:43 | Re: heap_create with OID? |