Re: 64-bit API for large objects

Поиск
Список
Период
Сортировка
От Jeremy Drake
Тема Re: 64-bit API for large objects
Дата
Msg-id Pine.LNX.4.63.0509241249570.5158@garibaldi.apptechsys.com
обсуждение исходный текст
Ответ на Re: 64-bit API for large objects  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: 64-bit API for large objects  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sat, 24 Sep 2005, Alvaro Herrera wrote:

> Hey,
>
> While you guys are hacking at the LO code, it would be nice to consider
> the suggestions outlined here:
>
> http://archives.postgresql.org/pgsql-bugs/2004-07/msg00143.php

Included from that message for easier reference:

> 0) In "Oid lo_creat(PGconn *conn, int mode)," why is there a mode on
> lo_create? The mode is determined when the object is lo_open()ed, right?

I think the docs basically said it is a vestigial feature, it used to be
useful but the code evolved in such a way that it ceased being useful.  It
is probably still there to allow old code to continue to compile against
newer servers without being recompiled.

> 1) There is no lo_truncate(PGconn *conn, int fd, off_t len).

Did not notice that one.  That is a good one to add if adding functions is
in the cards.  I bet when the person/people who are attempting to write to
this api here get far enough, they would have noticed that too ;)

> 2) There is no lo_length(PGconn *conn, int fd).

We did notice this one however.  There is also no lo_stat(PGconn *conn,
Oid lobjId).  I have been thinking about implementing these two.

I think I will make a revision of the patch at some point with these.  The
size ones will be extremely easy, the functionality is already there, just
a matter of exposing it.  The truncate is not too difficult, but actually
requires me to think a little more ;)

-- 
When does summertime come to Minnesota, you ask?  Well, last year, I
think it was a Tuesday.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeremy Drake
Дата:
Сообщение: Re: 64-bit API for large objects
Следующее
От: Tom Lane
Дата:
Сообщение: gcc4's uninitialized-variable warnings