From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Spiegelberg <gspiegelberg(at)cranel(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: OID assistance |
Date: | 2005-02-18 16:40:36 |
Message-ID: | 18969.1108744836@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Greg Spiegelberg <gspiegelberg(at)cranel(dot)com> writes:
> Tom Lane wrote:
>> Well, put a unique index on the contents column. Better to fail an
>> insert than to get a conflict of LO OIDs.
> Can't do that. Our app won't handle it.
Actually, I think the lo_import() will fail anyway, whether you like it
or not. There's a unique index on pg_largeobject.
> This does lead me to 2 questions... first, why is this still an issue and
> not fixed in the backend where OID's are managed?
When you're two major versions behind, you don't have a lot of leeway to
complain about why things are still an issue ;-). But the short answer
is that making OIDs 8 bytes would permanently break platforms that don't
have int64 support, and be a nontrivial performance hit on those where
int64 is substantially slower than int32. So I'd say it's a good ways
into the future yet. Eventually we'll decide we don't care about 32-bit
machines anymore, but not for awhile.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Geoffrey Ducharme | 2005-02-18 19:25:05 | Task manager fails to terminate postmaster process. |
Previous Message | Greg Spiegelberg | 2005-02-18 16:27:24 | Re: OID assistance |