Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Besides the MVCC issue, I am not sure it's a good idea LO being binded
> to OID. In my understanding OID is solely used to distinguish each LO
> in a database. In another word, it's just a key to LO. I think giving
> explicit key when creating a LO has some benefits:
I'm not excited about making non-backwards-compatible changes in LOs;
the whole thing is pretty much a legacy feature in my mind, and changing
it significantly seems to miss the point. However, we could offer a
new variant of lo_creat that allows a particular OID to be specified.
(That would simplify pg_dump tremendously, which is probably sufficient
reason to do it.) I think the only other change needed is that the
default form of lo_creat should loop until it finds a free OID, which
is something I had intended to change anyway --- the current coding is
failure-prone once the OID counter wraps around.
This is really orthogonal to the MVCC issue, but I'm willing to change
it at the same time if there's no objections.
Anyone have a preference about the name for the new function? (At least
at the libpq level, we have to invent a new name, we can't just
overload.) I'm inclined to use "lo_create", but maybe that's too close
to "lo_creat".
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
