Re: AW: OID wraparound: summary and proposal
От | Hiroshi Inoue |
---|---|
Тема | Re: AW: OID wraparound: summary and proposal |
Дата | |
Msg-id | 3B69F95C.DD67107A@tpf.co.jp обсуждение исходный текст |
Ответ на | AW: OID wraparound: summary and proposal (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
Ответы |
Re: AW: OID wraparound: summary and proposal
|
Список | pgsql-hackers |
Zeugswetter Andreas SB wrote: > > > Strangely enough, I've seen no objection to optional OIDs > > other than mine. Probably it was my mistake to have formulated > > a plan on the flimsy assumption. > > I for one am more concerned about adding additional per > tuple overhead (moving from 32 -> 64bit) than loosing OID's > on some large tables. Imho optional OID's is the best way to combine > both worlds. OID's only where you absolutely need them, and thus > a good chance that wraparound does not happen during the lifetime of > one application. (And all this by reducing overhead, and not adding > overhead :-) > Hmm there seems to be an assumption that people could know whether they need OID or not for each table. I've had a plan in ODBC using OID and TID. Few ODBC users know about ODBC spec. They rarely use ODBC directly and use middlewares like Access etc. Could they take care of the necessity of OIDs with my plan ? Could they know when/how the middlewares use my new feature effectively ? To tell the truth, I don't know it precisely. OK, a user decided to create tables with OIDs unco nditionally for ODBC but he may encounter the OID wraparound problem instead.... I don't think that people use the feature with such silly restrictions. regards, Hiroshi Inoue
В списке pgsql-hackers по дате отправления: