Re: BUG #1671: Long interval string representation rejected - Mailing list pgsql-bugs

From Neil Conway
Subject Re: BUG #1671: Long interval string representation rejected
Date
Msg-id 428BF214.3090406@samurai.com
Whole thread Raw
In response to Re: BUG #1671: Long interval string representation rejected  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #1671: Long interval string representation rejected  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #1672: Postgres 8.0 doesn't return errors.
Next
From: Neil Conway
Date:
Subject: Re: Fw: Error when install