Re: heap_create with OID?
От | Philip Warner |
---|---|
Тема | Re: heap_create with OID? |
Дата | |
Msg-id | 3.0.5.32.20000704174343.02546410@mail.rhyme.com.au обсуждение исходный текст |
Ответ на | Re: heap_create with OID? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: heap_create with OID?
|
Список | pgsql-hackers |
At 02:57 4/07/00 -0400, Tom Lane wrote: >Philip Warner <pjw@rhyme.com.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 |/
В списке pgsql-hackers по дате отправления: