Re: BUG #1671: Long interval string representation rejected

Поиск
Список
Период
Сортировка
От Neil Conway
Тема Re: BUG #1671: Long interval string representation rejected
Дата
Msg-id 428C953D.40308@samurai.com
обсуждение исходный текст
Ответ на Re: BUG #1671: Long interval string representation rejected  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #1671: Long interval string representation rejected  (Neil Conway <neilc@samurai.com>)
Список 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 по дате отправления:

Предыдущее
От: "Mohan, Ross"
Дата:
Сообщение: Re: [PORTS] Bug Report with Postgres 7.4 on AIX 5.3
Следующее
От: "Olleg Samoylov"
Дата:
Сообщение: BUG #1676: Statment order in rules