From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Fernando Nasser <fnasser(at)redhat(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: OID wraparound: summary and proposal |
Date: | 2001-08-07 15:36:41 |
Message-ID: | 4679.997198601@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fernando Nasser <fnasser(at)redhat(dot)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?
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ian Lance Taylor | 2001-08-07 15:59:13 | CURRENT OF cursor without OIDs |
Previous Message | Bruce Momjian | 2001-08-07 15:28:43 | Re: OID wraparound: summary and proposal |