Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

Next:From: Neil ConwayDate: 2005-05-19 13:40:10
Subject: Re: BUG #1674: CREATE TABLE "name" (with double quotes) and
Previous:From: Olleg SamoylovDate: 2005-05-19 13:30:12
Subject: BUG #1676: Statment order in rules

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group