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 428C953D.40308@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  (Neil Conway <neilc@samurai.com>)
List pgsql-bugs
Tom Lane wrote:
> I'm too tired to think about this more tonight, but it seems like
> the basic point is that we can't just construct a list of pointers
> into (a copy of) the original input string.

I think we _can_ do it that way, it's just a question of whether that is
the best approach. I think the solution I outlined before would work
fine: pass the length of the working buffer to ParseDateTime(), and
reject the input only if the parsing process actually requires more
working space than was provided. ParseDateTime() can easily skip
whitespace without storing it in the temporary buffer -- and once we've
done that, AFAIK we _can_ place an upper bound on the amount of working
space that is needed (each field has a maximum length and there are a
maximum number of fields).

Or we could rewrite how we do parsing, which seems to be what you're
suggesting. I agree the code could do with cleanup, although we will
also need some kind of minimally-invasive fix for back branches.

-Neil

pgsql-bugs by date:

Previous
From: "Mohan, Ross"
Date:
Subject: Re: [PORTS] Bug Report with Postgres 7.4 on AIX 5.3
Next
From: "Olleg Samoylov"
Date:
Subject: BUG #1676: Statment order in rules