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 428C0AD1.8080802@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:
> Well, if you allow for whitespace between tokens then it's immediately
> clear that there is no fixed upper bound.

Good point -- there is no upper bound on the input string, but since we
skip whitespace, AFAICS this shouldn't affect the requirements for the
size of the working buffer (lowstr). So if we passed the size of the
working buffer to ParseDateTime() (per earlier gripe), we could only
bail out when we actually need to use more working space than was
allocated, not simply when strlen(input) >= sizeof(buffer). The
implementation might be a bit ugly, though.

> Perhaps it would work to downcase just one token at a time, so that
> the max buffer length equals the max acceptable token?

Not sure I follow you.

-Neil

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #1671: Long interval string representation rejected
Next
From: Tom Lane
Date:
Subject: Re: BUG #1671: Long interval string representation rejected