Re: BUG #1671: Long interval string representation rejected

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

In response to

Responses

Browse pgsql-bugs by date

  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