Re: AW: OID wraparound: summary and proposal

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: AW: OID wraparound: summary and proposal
Date: 2001-08-03 01:07:40
Message-ID: 3B69F95C.DD67107A@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-08-03 01:09:25 Re: AW: OID wraparound: summary and proposal
Previous Message Tom Lane 2001-08-03 00:40:35 Re: Re: OID wraparound: summary and proposal