From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Mark Dilger <markdilger(at)yahoo(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #1671: Long interval string representation rejected |
Date: | 2005-05-19 13:31:41 |
Message-ID: | 428C953D.40308@samurai.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2005-05-19 13:40:10 | Re: BUG #1674: CREATE TABLE "name" (with double quotes) and |
Previous Message | Olleg Samoylov | 2005-05-19 13:30:12 | BUG #1676: Statment order in rules |