Re: BUG #1671: Long interval string representation rejected - Mailing list pgsql-bugs

From Neil Conway
Subject Re: BUG #1671: Long interval string representation rejected
Date
Msg-id 428C19C9.6070402@samurai.com
Whole thread Raw
In response to Re: BUG #1671: Long interval string representation rejected  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #1671: Long interval string representation rejected  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Tom Lane wrote:
> I believe that the reason for the local buffer is to hold a downcased
> version of the input, which we can compare to the all-lower-case tables
> of relevant keywords.

Well, that's one of the reasons, but not the only one. For example, how
do you parse '17 minutes31 seconds'::interval without either a working
buffer or the ability to resize the input buffer? (We need to split the
input into two fields, each of which must be a NUL-terminated string.
These fields are currently implemented as into the working buffer. If we
changed that to be pointers into the input string, we have no where to
put the NUL terminator. So you either need a separate buffer, repalloc()
plus shuffling everything down, or palloc'd allocation for the fields
themselves.) So I don't see that fixing the casing issue is sufficient.

On closer inspection, the current code seems to get this wrong as well
:-( For example, given the query:

select '4millenniums5centuries4decades1year4months4days17minutes31
seconds'::interval;

attaching via gdb, with a breakpoint at datetime.c:890 --

(gdb) p lp
$1 = 0xbfffdde1 "ÿÞ@"
(gdb) p lowstr + 25 + 51
$4 = 0xbfffdddc "onds"

(i.e. lp points past the end of lowstr)

-Neil

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #1671: Long interval string representation rejected
Next
From: Tom Lane
Date:
Subject: Re: BUG #1671: Long interval string representation rejected