strange result from contrib/seg regression on windows
I am seeing this (among other things) when running the seg contrib
module regression:
***************
*** 418,425 ****
ERROR: bad seg representation
DETAIL: syntax error at or near "e"
SELECT '1e700'::seg AS seg;
! ERROR: syntax error
! DETAIL: numeric value 1e700 unrepresentable
--
-- testing the operators
--
--- 418,428 ----
ERROR: bad seg representation
DETAIL: syntax error at or near "e"
SELECT '1e700'::seg AS seg;
! seg
! -----
! 1
! (1 row)
!
--
-- testing the operators
--Does anyone have a clue why? Can it be fixed? (I'll keep digging, but I
thought someone might be able to say immediately what it is.)
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
Does anyone have a clue why?
Evidently your sscanf isn't setting errno for overflow --- look at
seg_atof() in segparse.y.
This code shows several other signs of severe brain death, actually,
like leaking 256 bytes on each call for an error message buffer that it
doesn't even need :-( I'd recommend ripping the whole thing out and
replacing with a call to float4in.
regards, tom lane
Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
Does anyone have a clue why?
Evidently your sscanf isn't setting errno for overflow --- look at
seg_atof() in segparse.y.This code shows several other signs of severe brain death, actually,
like leaking 256 bytes on each call for an error message buffer that it
doesn't even need :-( I'd recommend ripping the whole thing out and
replacing with a call to float4in.
Yeah. If anyone can do this quickly I'd be grateful. Otherwise it will
probably be a few days before I get it done.
Alternatively, could we not just use strtof instead of sscanf?
cheers
andrew
Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
Does anyone have a clue why?
Evidently your sscanf isn't setting errno for overflow --- look at
seg_atof() in segparse.y.This code shows several other signs of severe brain death, actually,
like leaking 256 bytes on each call for an error message buffer that it
doesn't even need :-( I'd recommend ripping the whole thing out and
replacing with a call to float4in.
Patch and alternative regression result file attached (Thanks to Tom for
an assist).
cheers
andrew
Attachments:
seg.patchtext/x-patch; name=seg.patchDownload
Index: contrib/seg/segparse.y
===================================================================
RCS file: /home/cvsmirror/pgsql/contrib/seg/segparse.y,v
retrieving revision 1.14
diff -c -r1.14 segparse.y
*** contrib/seg/segparse.y 14 Sep 2004 04:21:38 -0000 1.14
--- contrib/seg/segparse.y 19 Oct 2004 15:16:56 -0000
***************
*** 2,7 ****
--- 2,9 ----
#define YYPARSE_PARAM result /* need this to pass a pointer (void *) to yyparse */
#include "postgres.h"
+ #include "fmgr.h"
+ #include "utils/builtins.h"
#include <math.h>
***************
*** 129,149 ****
%%
! float seg_atof ( char *value ) {
float result;
! char *buf = (char *) palloc(256);
!
! errno = 0;
! sscanf(value, "%f", &result);
!
! if ( errno ) {
! snprintf(buf, 256, "numeric value %s unrepresentable", value);
! ereport(ERROR,
! (errcode(ERRCODE_SYNTAX_ERROR),
! errmsg("syntax error"),
! errdetail("%s", buf)));
! }
return result;
}
--- 131,143 ----
%%
! float seg_atof ( char *value )
! {
float result;
! Datum datum;
+ datum = DirectFunctionCall1(float4in, CStringGetDatum(value));
+ result = DatumGetFloat4(datum);
return result;
}
Index: contrib/seg/expected/seg.out
===================================================================
RCS file: /home/cvsmirror/pgsql/contrib/seg/expected/seg.out,v
retrieving revision 1.9
diff -c -r1.9 seg.out
*** contrib/seg/expected/seg.out 14 Sep 2003 02:18:49 -0000 1.9
--- contrib/seg/expected/seg.out 19 Oct 2004 15:22:30 -0000
***************
*** 418,425 ****
ERROR: bad seg representation
DETAIL: syntax error at or near "e"
SELECT '1e700'::seg AS seg;
! ERROR: syntax error
! DETAIL: numeric value 1e700 unrepresentable
--
-- testing the operators
--
--- 418,424 ----
ERROR: bad seg representation
DETAIL: syntax error at or near "e"
SELECT '1e700'::seg AS seg;
! ERROR: "1e700" is out of range for type real
--
-- testing the operators
--
Andrew Dunstan <andrew@dunslane.net> writes:
This code shows several other signs of severe brain death, actually,
like leaking 256 bytes on each call for an error message buffer that it
doesn't even need :-( I'd recommend ripping the whole thing out and
replacing with a call to float4in.Patch and alternative regression result file attached (Thanks to Tom for
an assist).
Applied.
regards, tom lane