Bruce Momjian writes:
> I think we are at a point that people running on systems with no int64
> support should not expect to get valid return values for >2 billion row
> COPY operations.
I agree, there's no need to work harder on this than changing the
datatype to uint64.
There are some places
Also, can I get a context diff for the patch? See the developers FAQ
for information on how our patch process works. Thanks.
---
Volkan YAZICI wrote:
> On Dec 16 08:47, Bruce Momjian wrote:
> > I think an int64 is the prop
Volkan YAZICI wrote:
> On Dec 16 08:47, Bruce Momjian wrote:
> > I think an int64 is the proper solution. If int64 isn't really
> > 64-bits, the code should still work though.
>
> (I'd prefer uint64 instead of an int64.) In src/include/c.h, in
> this or that way it'll assign a type for uint64, so
On Dec 16 08:47, Bruce Momjian wrote:
> I think an int64 is the proper solution. If int64 isn't really
> 64-bits, the code should still work though.
(I'd prefer uint64 instead of an int64.) In src/include/c.h, in
this or that way it'll assign a type for uint64, so there won't
be any problem for bo
Volkan YAZICI wrote:
> I prepared a patch for "Have COPY return the number of rows
> loaded/unloaded?" TODO. (Sorry for disturbing list with such a simple
> topic, but per warning from Bruce Momjian, I send my proposal to -hackers
> first.)
>
> I used the "appending related information to commandT
I prepared a patch for "Have COPY return the number of rows
loaded/unloaded?" TODO. (Sorry for disturbing list with such a simple
topic, but per warning from Bruce Momjian, I send my proposal to -hackers
first.)
I used the "appending related information to commandTag" method which is
used for INSE
