RE: Re: AW: Re: OID wraparound: summary and proposal
От | Hiroshi Inoue |
---|---|
Тема | RE: Re: AW: Re: OID wraparound: summary and proposal |
Дата | |
Msg-id | EKEJJICOHDIEMGPNIFIJKEDIFBAA.Inoue@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: Re: AW: Re: OID wraparound: summary and proposal (Alex Pilosov <alex@pilosoft.com>) |
Список | pgsql-hackers |
> -----Original Message----- > From: Alex Pilosov > > On Mon, 6 Aug 2001, mlw wrote: > > > Zeugswetter Andreas SB SD wrote: > > > > > > > It seems to me, I guess and others too, that the OID > mechanism should > > > be on a > > > > per table basis. That way OIDs are much more likely to be > unique, and > > > TRUNCATE > > > > on a table should reset it's OID counter to zero. > > > > > > Seems to me, that this would be no different than a > performance improved > > > version > > > of SERIAL. > > > If you really need OID, you imho want the systemid tableid tupleid > > > combo. > > > A lot of people seem to use OID, when they really could use XTID. That > > > is > > > what I wanted to say. > > > > > > > I don't care about having an OID or ROWID, I care that there is > a 2^32 limit to > > the current OID strategy and that a quick fix of allowing > tables to exist > > without OIDs may break some existing software. I was suggesting > the OIDs be > > managed on a "per table" basis as a better solution. > Again, what existing software demands per-table OID field? Isn't it what > primary keys are for? > I was just about to implement updatable cursors in psqlODBC using TID and OID. I've half done it but the rest is pending now. I've had the the plan since I introduced Tid scan in 7.0. regards, Hiroshi Inoue
В списке pgsql-hackers по дате отправления: