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 05:30:15 |
Message-ID: | 428C2467.6090904@samurai.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Tom Lane wrote:
> Sorry, s/downcased/downcased and null-terminated/. I have not read the
> parsing code in question lately, but offhand it seems like transferring
> one token at a time into a work buffer isn't a completely broken idea...
I wouldn't call it "broken", but I don't see how it could be done
without a significant refactoring of how datetime parsing is done, and
your handwaving has yet to convince me :) The gist of the current code is:
1. parse the input string into fields, which are arrays of pointers into
a working buffer, via ParseDateTime()
2. decode the fields as appropriate for the datatype via
DecodeInterval(), DecodeDatetime(), DecodeTimeOnly(), etc.
i.e. I don't see an easy way to do field decoding one field at a time.
-Neil
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-05-19 05:49:54 | Re: BUG #1671: Long interval string representation rejected |
Previous Message | Tom Lane | 2005-05-19 05:05:54 | Re: BUG #1671: Long interval string representation rejected |