Neil Conway wrote:
Ah, yeah, that works. Attached is a revised patch -- I'll apply it
tomorrow barring any objections. I also fixed the semi-colon -- thanks
for the review.
Patch applied to HEAD, REL8_0_STABLE, and REL7_4_STABLE. Thanks for the
report, Mark.
-Neil
-
Tom Lane wrote:
Considering that you're incrementing bufptr inside the macro, it hardly
seems that double-evaluation is a problem: the argument pretty much has
to be a variable. OTOH there is no reason for the input argument to be
treated that way. I'd suggest just one macro [...]
Ah, yeah, t
I wrote:
> #define APPEND_CHAR(bufptr, end, newchar) \
> do \
> { \
> if (((bufptr) + 1) >= (end)) \
> return DTERR_BAD_FORMAT; \
> *(bufptr)++ = (newchar); \
> } while (0);
Oh BTW, there definitely should not be a semicolon at th
Neil Conway <[EMAIL PROTECTED]> writes:
> Attached is a patch that implements this. I'm not especially happy about
> the implementation: defining _two_ local macros (that both
> doubly-evaluate one of their arguments) is pretty ugly, but I didn't see
> a cleaner alternative -- suggestions welcom
Tom Lane wrote:
I'm not set on it --- fix it as you suggested.
Attached is a patch that implements this. I'm not especially happy about
the implementation: defining _two_ local macros (that both
doubly-evaluate one of their arguments) is pretty ugly, but I didn't see
a cleaner alternative --
Neil Conway <[EMAIL PROTECTED]> writes:
> Any thoughts on this, Tom? If you're planning on doing the rewrite you
> described, that's fine; alternatively I'm happy to implement the fix
> that I described above.
I'm not set on it --- fix it as you suggested.
regards, tom l
Neil Conway wrote:
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 mor
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 s
Neil Conway <[EMAIL PROTECTED]> writes:
> your handwaving has yet to convince me :)
Zing ;-)
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. A certain amount of
data c
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
Neil Conway <[EMAIL PROTECTED]> writes:
> 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 exampl
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
Neil Conway <[EMAIL PROTECTED]> writes:
>> Perhaps it would work to downcase just one token at a time, so that
>> the max buffer length equals the max acceptable token?
> Not sure I follow you.
I believe that the reason for the local buffer is to hold a downcased
version of the input, which we ca
Tom Lane wrote:
Well, if you allow for whitespace between tokens then it's immediately
clear that there is no fixed upper bound.
Good point -- there is no upper bound on the input string, but since we
skip whitespace, AFAICS this shouldn't affect the requirements for the
size of the working buffe
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 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.
> I'm no
Tom Lane wrote:
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
p
Neil Conway <[EMAIL PROTECTED]> 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
Mark Dilger wrote:
It appears that any string representation of an interval of length greater
than 76 is rejected. (76 = 51 + 25 = MAXDATELEN + MAXDATEFIELDS). This
appears to be a limitation enforced within function interval_in() in the
file src/backend/utils/adt/timestamp.c
Yeah, this seems bog
The following bug has been logged online:
Bug reference: 1671
Logged by: Mark Dilger
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.2
Operating system: Mandrake Linux 9.1 (2.4.21-0.13mdkenterprise #1 SMP)
Description:Long interval string representation rejec
19 matches
Mail list logo
