Re: Largeobject Access Controls (r2460)
От | KaiGai Kohei |
---|---|
Тема | Re: Largeobject Access Controls (r2460) |
Дата | |
Msg-id | 4B21F8CE.108@ak.jp.nec.com обсуждение исходный текст |
Ответ на | Re: Largeobject Access Controls (r2460) (Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>) |
Ответы |
Re: Largeobject Access Controls (r2460)
|
Список | pgsql-hackers |
Takahiro Itagaki wrote: > KaiGai Kohei <kaigai@ak.jp.nec.com> wrote: > >> The attached patch fixes these matters. > > I'll start to check it. Thanks, >> We have to reference pg_largeobject_metadata to check whether a certain >> large objct exists, or not. > > What is the situation where there is a row in pg_largeobject_metadata > and no corresponding rows in pg_largeobject? Do we have a method to > delete all rows in pg_largeobject but leave some metadata? It is a case when we create a new large object, but write nothing. postgres=# SELECT lo_create(1234); lo_create ----------- 1234 (1 row) postgres=# SELECT * FROM pg_largeobject_metadata WHERE oid = 1234; lomowner | lomacl ----------+-------- 10 | (1row) postgres=# SELECT * FROM pg_largeobject WHERE loid = 1234; loid | pageno | data ------+--------+------ (0 rows) In this case, the following two queries are not equivalent.* SELECT oid FROM pg_largeobject_metadata* SELECT DISTINCT loidFROM pg_largeobject The second query does not return the loid of empty large objects. The prior implementation inserted a zero-length page to show here is a large object with this loid, but it got unnecessary with this enhancement. If we need compatibility in this level, we can insert a zero-length page into pg_largeobject on LargeObjectCreate(). It is harmless, but its worth is uncertain. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
В списке pgsql-hackers по дате отправления: