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.
> If you were on 7.4 or later you could do ALTER TABLE SET WITHOUT OIDS so
> you'd not be sucking up OIDs for the table rows themselves. On 7.3 the
> only way would be to drop and recreate the larger tables WITHOUT OIDS,
> which is probably going to be painful :-(.
I figured as much. We're working to automate the dump-restore-alter table
process now.
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? Second, shouldn't there
be something like "use WITHOUT OIDS for data warehouses" be in the FAQ?
Thanks for the quick response.
Greg
--
Greg Spiegelberg
Product Development Manager
Cranel, Incorporated.
Phone: 614.318.4314
Fax: 614.431.8388
Email: gspiegelberg@cranel.com
Technology. Integrity. Focus.
