Em 06-02-2011 13:09, Bruce Momjian escreveu:
What happened to this idea/patch?
I refactored the patch [1] to not depend on strtoll.
[1] http://archives.postgresql.org/message-id/4d2cccd9@timbira.com
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hackers mai
What happened to this idea/patch?
---
Greg Smith wrote:
> Tom Lane wrote:
> > Please choose a way that doesn't introduce new portability assumptions.
> > The backend gets along fine without strtoll, and I don't see why pgben
Tom Lane wrote:
Please choose a way that doesn't introduce new portability assumptions.
The backend gets along fine without strtoll, and I don't see why pgbench
should have to require it.
Funny you should mention this...it turns out there is some code already
there, I just didn't notice it
On Tue, Jul 6, 2010 at 11:01 AM, Greg Smith wrote:
> Robert Haas wrote:
>>
>> It doesn't seem very palatable to have multiple handwritten integer
>> parsers floating around the code base either. Maybe we should try to
>> standardize something and ship it in src/port, or somesuch
>
> I was conside
Robert Haas wrote:
It doesn't seem very palatable to have multiple handwritten integer
parsers floating around the code base either. Maybe we should try to
standardize something and ship it in src/port, or somesuch
I was considering at one point making two trips through strtol, each
allowed t
On Mon, Jul 5, 2010 at 8:17 PM, Tom Lane wrote:
> Greg Smith writes:
>> The main tricky part was figuring how to convert the \setshell
>> implementation. That uses strtol to parse the number that should have
>> been returned by the shell call. It turns out there are a stack of ways
>> to do som
Greg Smith writes:
> The main tricky part was figuring how to convert the \setshell
> implementation. That uses strtol to parse the number that should have
> been returned by the shell call. It turns out there are a stack of ways
> to do something similar but return 64 bits instead:
Please c
Attached is an updated second rev of the patch I sent a few months ago,
to expand pgbench to support database scales larger than around
4,294--where the 32-bit integer for the account number overflows in the
current version. The current limit makes for about a 60GB database.
Last week I ran t
