Re: Strange interval arithmetic
От | Michael Fuhr |
---|---|
Тема | Re: Strange interval arithmetic |
Дата | |
Msg-id | 20051130215018.GA24778@winnie.fuhr.org обсуждение исходный текст |
Ответ на | Re: Strange interval arithmetic (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Strange interval arithmetic
Re: Strange interval arithmetic |
Список | pgsql-hackers |
On Wed, Nov 30, 2005 at 02:01:46PM -0500, Tom Lane wrote: > Michael Fuhr <mike@fuhr.org> writes: > > Any preferences on an approach? The simplest and easiest to verify > > would be to raise an error for just this particular case; a TODO > > item might be to change how the string is parsed to allow values > > larger than LONG_MAX. > > I think the latter would be a feature enhancement and therefore not > good material to back-patch. Just erroring out seems appropriate > for now. Agreed. I'm thinking about rewriting strtol() calls in datetime.c to look like this: errno = 0; val = strtol(field[i], &cp, 10); if (errno == ERANGE) return DTERR_FIELD_OVERFLOW; Does that look okay? Or would you rather raise an error with ereport()? > > I see several calls to strtol() that aren't checked for overflow but > > that might not be relevant to this problem, so I'm thinking this patch > > ought not touch them. Maybe that's another TODO item. > > If it's possible for them to be given overflowing input, they probably > ought to be checked. I'm looking at all the strtol() calls in datetime.c right now; I haven't looked anywhere else yet. Should I bother checking values that will be range checked later anyway? Time zone displacements, for example? -- Michael Fuhr
В списке pgsql-hackers по дате отправления: