RE: Re: 7.2 items
От | Franck Martin |
---|---|
Тема | RE: Re: 7.2 items |
Дата | |
Msg-id | F12ECEA0435AD211B5280008C7ACBC857FF62C@BIGIRON обсуждение исходный текст |
Ответ на | 7.2 items (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
I think OID should be truly unique in the world as to make it easier for replication. If OID are real unique number (not in a table, not in a database, but in the world) then replication can be easily built with OIDs... Cheers. Franck Martin Network and Database Development Officer SOPAC South Pacific Applied Geoscience Commission Fiji E-mail: franck@sopac.org <mailto:franck@sopac.org> Web site: http://www.sopac.org/ <http://www.sopac.org/> Support FMaps: http://fmaps.sourceforge.net/ <http://fmaps.sourceforge.net/> This e-mail is intended for its addresses only. Do not forward this e-mail without approval. The views expressed in this e-mail may not be necessarily the views of SOPAC. -----Original Message----- From: Lincoln Yeoh [mailto:lyeoh@pop.jaring.my] Sent: Monday, 14 May 2001 3:45 To: Bruce Momjian; PostgreSQL-development Subject: [HACKERS] Re: 7.2 items At 01:20 PM 10-05-2001 -0400, Bruce Momjian wrote: >Here is a small list of big TODO items. I was wondering which ones >people were thinking about for 7.2? > >--------------------------------------------------------------------------- 4) Not really important to me but can serial be a proper type or something so that drop table will drop the linked sequence as well? Maybe:serial = old serial for compatibilityserial4 = new serialserial8 = new serial using bigint (OK so 2 billion is big, but...) 5) How will the various rollovers be handled e.g. OID, TID etc? What happens if OIDs are not unique? As things get faster and bigger a nonunique OID in a table might just happen. Cheerio, Link. ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly
В списке pgsql-hackers по дате отправления: