| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Neil Conway <neilc(at)samurai(dot)com> |
| 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-18 06:04:06 |
| Message-ID: | 17757.1116396246@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Neil Conway <neilc(at)samurai(dot)com> writes:
> Yeah, this seems bogus. It's not even clear to me why MAXDATELEN +
> MAXDATEFIELDS is used as the size of that buffer in the first place. I
> don't know the datetime code particularly well; perhaps someone who does
> can shed some light on this?
My rule of thumb with the datetime code is that if it looks bogus,
it probably is :-(
There are a lot of fixed-size local buffers in that code. The ones
used in output routines seem defensible since the string to be generated
is predictable. The ones that are used for processing input are likely
wrong. OTOH I'm not eager to throw a palloc into each of those code
paths ... can we avoid that?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory L Miller-Kramer | 2005-05-18 13:11:00 | Re: BUG #1672: Postgres 8.0 doesn't return errors. |
| Previous Message | Neil Conway | 2005-05-18 05:43:53 | Re: BUG #1671: Long interval string representation rejected |