Thread added to TODO. As far as I can see, this thread never produced
an patch that could be applied.
---
Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
On Fri, 23 Sep 2005, Tom Lane wrote:
postgresql-fe.h
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
On Fri, 23 Sep 2005, Tom Lane wrote:
postgresql-fe.h
On Sat, Sep 24, 2005 at 12:13:11PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
On Fri, Sep 23, 2005 at 05:40:09PM -0400, Tom Lane wrote:
For that matter, we can't even guarantee that they work at all: not
all platforms even *have* int64 types.
What platforms that PG
Jim C. Nasby [EMAIL PROTECTED] writes:
So what happens if you attempt to put a value greater than 2^32 into a
bigint on a non-int64 platform?
You get the same error as if you tried to store a value greater than 2^64.
regards, tom lane
---(end of
Jeremy Drake [EMAIL PROTECTED] writes:
On Fri, 23 Sep 2005, Tom Lane wrote:
postgresql-fe.h defines a ton of stuff that has no business being
visible to libpq's client applications. It's designed to be used by
our *own* client-side code (psql and the like), but we have not made
any attempt
Jeremy Drake [EMAIL PROTECTED] writes:
In any case, are there any comments on the changes below libpq (the
functions visible to queries on down)?
Within the backend, I don't see the point in maintaining a distinction
between 32- and 64-bit APIs for inv_api.c: you should just switch 'em
to use
On Fri, 23 Sep 2005, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] 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
David Fetter [EMAIL PROTECTED] writes:
On Fri, Sep 23, 2005 at 05:40:09PM -0400, Tom Lane wrote:
For that matter, we can't even guarantee that they work at all: not
all platforms even *have* int64 types.
What platforms that PG supports don't have int64 arithmetic?
We claim to build with any
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
--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
Y una voz del caos me habló y me dijo
On Sat, 24 Sep 2005, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
In any case, are there any comments on the changes below libpq (the
functions visible to queries on down)?
Within the backend, I don't see the point in maintaining a distinction
between 32- and 64-bit APIs for
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
Jeremy Drake [EMAIL PROTECTED] writes:
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
This patch implements the ability for large objects to be larger than 2GB.
I believe the limit to now be about 2TB, based on the fact that the large
object page size is 2048 bytes, and the page number is still 32 bits.
There are a few things about this patch which probably require tweaking or
at
Jeremy Drake [EMAIL PROTECTED] 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
On Fri, Sep 23, 2005 at 05:40:09PM -0400, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
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,
Jeremy Drake [EMAIL PROTECTED] writes:
On Fri, 23 Sep 2005, Tom Lane wrote:
Unfortunately that's completely unacceptable from a namespace-pollution
point of view.
I don't quite understand.
postgresql-fe.h defines a ton of stuff that has no business being
visible to libpq's client
I sent this from the wrong address last time so it did not go to the list,
I apologize to anyone who may be getting it again...
On Fri, 23 Sep 2005, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
2) The lo_*64, in order to be convenient from the client end, have
functions added to
On Fri, 23 Sep 2005, Tom Lane wrote:
postgresql-fe.h defines a ton of stuff that has no business being
visible to libpq's client applications. It's designed to be used by
our *own* client-side code (psql and the like), but we have not made
any attempt to keep it from defining stuff that
Cool. We look forward to it.On 9/19/05, Mark Dilger [EMAIL PROTECTED] wrote:
Jonah H. Harris wrote: Mark, If you don't mind contributing the changes, we'd be glad to take a look at them.Thanks. -JonahOk, we will post it back soon.We have tested it on two different 64-bit
architectures (Sparc and
Mark,
If you don't mind contributing the changes, we'd be glad to take a look at them. Thanks.
-JonahOn 9/18/05, Mark Dilger [EMAIL PROTECTED] wrote:
My company has written a 64-bit large object API, extending the postgresqlserver to be able to read/write/seek/tell/open/close objects larger than
Jonah H. Harris wrote:
Mark,
If you don't mind contributing the changes, we'd be glad to take a look
at them. Thanks.
-Jonah
Ok, we will post it back soon. We have tested it on two different 64-bit
architectures (Sparc and AMD) and are now testing on pentium before posting up
to the
My company has written a 64-bit large object API, extending the postgresql
server to be able to read/write/seek/tell/open/close objects larger than 2GB.
If the hackers community considers this valuable, we will submit the changes
back for the rest of the community to share.
From one of my
22 matches
Mail list logo
