Re: BUG #1671: Long interval string representation rejected

Tom Lane wrote:
> There are a lot of fixed-size local buffers in that code. The ones
> used in output routines seem defensible since the string to be generated
> is predictable. The ones that are used for processing input are likely
> wrong. OTOH I'm not eager to throw a palloc into each of those code
> paths ... can we avoid that?

I'm not sure offhand what the upper bounds on legal input for each of
the datetime types is. Why not just allocate a larger but still
fixed-size buffer -- say, 256 bytes?

(While we're on the subject, it seems rather silly for ParseDateTime()
not to do its own bounds checking -- all of its call sites do a strlen()
on the input buffer before calling it, which could be avoided if
ParseDateTime() we passed the size of `lowstr')

-Neil