Paul Caskey <paul@nmxs.com> writes:
> Tom Lane wrote:
>>>> I don't rely on OID uniqueness, but I assumed Postgres does!
>>
>> Only in the system tables, and not even in all of them. From the
>> system's point of view, there's no real need to assign OIDs to
>> user table rows at all --- so another possible answer is not to
>> do that, unless the user requests it.
> That's interesting (almost shocking) to know, but it's probably too late
> to put the lid back on that bottle. I imagine a lot of software has been
> written especially for postgres, like pgaccess, which use the oid field
> along with cursors, etc. A lot of people have probably also relied on the
> oid as a convenient unique record identifier.
Indeed, I have written such applications myself (though only after
estimating they'd not exceed 4G rows before my children's children's
children are safely dead ;-)). This is why we'd have to continue to
offer OIDs for user tables as an option. Whether it should be default
or not is debatable.
Personally I prefer the straight-ahead approach of supporting wider
OIDs. Sooner or later we will need to be able to handle wider-than-
32bit transaction IDs and block numbers too, and there's no cute
workaround for those. Might as well get some practice with OIDs.
> FWIW, I checked into MySQL, and as far as I can tell, they have nothing
> like this implicit 4 billion transactional "limit".
Hmph. Has anyone ever come close to shoving 4G rows into MySQL? Maybe
they just haven't documented their limits...
regards, tom lane