Re: Concrete proposal for large objects and MVCC
От | Tom Lane |
---|---|
Тема | Re: Concrete proposal for large objects and MVCC |
Дата | |
Msg-id | 23750.1118423340@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Concrete proposal for large objects and MVCC (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Список | pgsql-hackers |
Tatsuo Ishii <t-ishii@sra.co.jp> 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
В списке pgsql-hackers по дате отправления: