>Breaking all the client-visible LO APIs, for one thing ...
>
>
>
Erck.
>> 1. 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.
>
>
>
Well number 2 is that we have a limit on total number of OID's yes?
Which means
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 - jd@commandprompt.com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
