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
