Joshua D. Drake [EMAIL PROTECTED] writes:
pg_largeobject uses a loid identifier for the loid. What do we think it
would take to move that identifier to something like bigint?
Breaking all the client-visible LO APIs, for one thing ...
I don't really
know the underlying internals of
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.
Joshua D. Drake [EMAIL PROTECTED] writes:
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?
pg_largeobject already has an index (which is
pg_largeobject already has an index (which is used by all the LO
operations). Again, don't see what the width of the object ID column
has to do with it.
I was more after the not having an OID than the width of the ID column.
regards, tom lane
---(end of
Joshua D. Drake [EMAIL PROTECTED] writes:
I was more after the not having an OID than the width of the ID column.
We're still at cross-purposes then. pg_largeobject doesn't have OIDs
(in the sense of per-row OIDs). What I thought you were complaining
about was the chosen datatype of the LO
We're still at cross-purposes then. pg_largeobject doesn't have OIDs
(in the sense of per-row OIDs). What I thought you were complaining
about was the chosen datatype of the LO identifier column (loid), which
happens to be OID.
O.k. that was my main concern, which per your statement is
