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 pgbench
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
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
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
On Tue, Jul 6, 2010 at 11:01 AM, Greg Smith g...@2ndquadrant.com 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
Greg Smith g...@2ndquadrant.com 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
On Mon, Jul 5, 2010 at 8:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Smith g...@2ndquadrant.com 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