Re: 64-bit API for large objects
От | Jeremy Drake |
---|---|
Тема | Re: 64-bit API for large objects |
Дата | |
Msg-id | Pine.LNX.4.63.0509231936220.5158@garibaldi.apptechsys.com обсуждение исходный текст |
Ответ на | Re: 64-bit API for large objects (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Fri, 23 Sep 2005, Tom Lane wrote: > Jeremy Drake <pgsql@jdrake.com> writes: > > 2) The lo_*64, in order to be convenient from the client end, have > > functions added to libpq as the existing lo_* functions. The client side > > of libpq did not previously know anything about int64 or how to > > send/receive them. I added an include of postgres-fe.h (which according > > to the comment in that file looks like it should go there) so int64 would > > be defined, > > Unfortunately that's completely unacceptable from a namespace-pollution > point of view. I don't quite understand. Allow me to cite the source, so we both are referring to the same thing here... jeremyd@pluto postgresql-8.0.3 $ head -n17 src/include/postgres_fe.h /*-------------------------------------------------------------------------** postgres_fe.h* Primary include filefor PostgreSQL client-side .c files** This should be the first file included by PostgreSQL client libraries and* applicationprograms --- but not by backend modules, which should include* postgres.h.*** Portions Copyright (c) 1996-2005,PostgreSQL Global Development Group* Portions Copyright (c) 1995, Regents of the University of California** $PostgreSQL:pgsql/src/include/postgres_fe.h,v 1.10 2004/12/31 22:03:19 pgsql Exp $**-------------------------------------------------------------------------*/ Now I may not completely understand the term "client", but I think libpq is a "client library" and anything which may use it would be an "application program". So it seems it was an oversight on the part of libpq to not include it. Does the term "client" not mean what I thought it did (anything which connects to a postgresql server)? > > The real problem here is that int64 isn't a well-defined portable > datatype, and so it's going to be very hard to export these functions in > a way that won't break on different platforms, applications compiled > with a different compiler than libpq was, etc. Umm, what wouldn't break if you switched compilers in a way that redefined sizeof(things)? I happen to know, even using the same compiler but just changing a compile flag (-m64) which changes sizes of integral types (sizeof(long) from 32 to 64 bits) will make such actions stop working on one of my tested platform. It sucks, I happen to not be fond of this because I tend not to have every library which is on my box built for both, but it is the way life is. I do not know of a platform where the size of an integral type can change and still be able to link against libraries and things. And if the size of some type is not changing, then things should already be correctly set for the platform. But I admit I have not met every platform in existance. Do you happen to be able to cite a platform where this is the case? > > For that matter, we can't even guarantee that they work at all: not all > platforms even *have* int64 types. We have so far avoided putting any > fundamental dependencies on int64 arithmetic into the system, and I'm a > bit worried that this patch will break LO support entirely on platforms > that don't have working int64 arithmetic. They should in fact break gracefully on such platforms, or at least as gracefully as any other int64-using code might. I did check a couple places for #ifdef INT64_BROKEN (or whatever it was called) to make sure that on those platforms something at least somewhat sane would happen. (they use 32 bits instead). Also, on those platforms, you could always use the non-64 versions if you were concerned about that. The patches would allow seeking past the old limit using the 32 function in stages (seek 2G, seek 2G, seek 2G would put you at 6G) if you do not mind wierd return values and tell not working. And if you use a platform which does not support 64bit integral types, then you cannot reasonably expect those functions to work correctly anyway. But they should compile at least. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match > -- I don't wanna argue, and I don't wanna fight, But there will definitely be a party tonight...
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Ron PeacetreeДата:
Сообщение: Re: [PERFORM] Releasing memory during External sorting?