Re: Limiting factors of pg_largeobject

>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