Tom Lane wrote:
>
> Fernando Nasser <fnasser@redhat.com> writes:
> > The wire protocol will always handle the (tableoid) long form,
>
> I think you are handwaving away what is precisely the most painful
> aspect. To allow 64-bit type OIDs in the wire protocol, we must
> (a) have a protocol version jump, and (b) force all servers and all
> client libraries to be 64-bit-capable. While I'm prepared to think
> that "int8 is really only 32 bits wide" is tolerable within a single
> server installation, I really don't want to deal with such headaches
> between clients and servers. Can you imagine how hard it will be
> to track down a bug that arises because one old client is dropping
> the high-order bits of type OIDs? Only installations that had been
> up for years would ever see a problem; how likely is it that anyone
> would even remember that some of their clients were not 64-bit-ready?
>
A protocol bump is inevitable if we ever want to deal with 64 bit OIDs,
so the sooner we do it the better.
Someone pointed out that even with optional OIDs and per table OIDs,
we would still need to allow per table OIDs to be more than 32 bits
(I am taking his word for it). If that is the case, the scenario you
described above is inevitable.
> When we're ready to make that jump, I think we should just move to
> 64 bit OIDs, full stop, no exceptions, no turning back, no "configure
> time option", no backwards compatibility with old clients. Anything
> else is a time bomb. I'd even be inclined to start running the OID
> counter at 4-billion-plus-1, to help flush out anyplace that drops the
> high half.
>
That would be the way to go. We are just trying to buy some time with
the other measures.
But some folks are complaining of having to use 64 bit OIDs when they
don't really need them, so that is why I proposed the OID32/OID64 option.
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
