Breaking all the client-visible LO APIs, for one thing ...Erck.
Well number 2 is that we have a limit on total number of OID's yes? Which means1. A larger identifier
2. An identifier that is not typed to the underlying system (oid)
3. The ability to be indexed
We may benefit. Am I on crack?
I don't see what you're getting at with #2 and #3 at all. OID is perfectly indexable.
we could theorectically run out of OID's because of pg_largeobject.
The ability to be indexed is obviously there but one problem we have is that you can't create an index on a system table at least not a user level index. Is there system level indexes that I am unaware of?
As for #1, it'd theoretically be useful, but I'm not sure about the real-world usefulness. If your large objects are even moderately "large" (for whatever value of "large" applies this week), you're not likely to be expecting to cram 4 billion of them into your database.
If we were doing LOs over for some reason it might be interesting to consider this, but I think they're largely a legacy feature at this point, and not worth that kind of effort. It would be better to put the development effort on creating serial access capability to toasted fields, whereupon LOs would really be obsolete.
regards, tom lane
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
-- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
