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-f
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-f
"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
---(e
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 platfor
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 s
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
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 API
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
"Sonr
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 wi
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
>
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 us
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
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 w
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 adde
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 appl
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,
> a
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 pos
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 l
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.>> -Jonah>Ok, we will post it back soon. We have tested it on two different 64-bit
architectures
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 li
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 th
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 pro
22 matches
Mail list logo
