Re: [PATCHES] Bug in date.c

[Tom Lane]

Gregory Stark <[EMAIL PROTECTED]> writes:
> There's a bug in datetime.c when it handles errors converting text into
> various date formats. It tries to avoid palloc'ing a cstring copy of the in=
> put
> by storing it in a stack variable instead but that means it can't handle
> inputs over MAXDATELEN. So it throws an error but passes the varlena string
> where the format expects a c string. Of course having to generate a c string
> for the format begs the question...

Good catch.  I'm hoping that all three of these functions will go away
before 8.3 is out (in favor of a generic text cast capability), but we
need a back-patchable fix for the released branches.  So the "minimal"
patch looks the best to me --- least risk of patch trouble.

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

[PATCHES] Bug in date.c

[Gregory Stark]

There's a bug in datetime.c when it handles errors converting text into
various date formats. It tries to avoid palloc'ing a cstring copy of the input
by storing it in a stack variable instead but that means it can't handle
inputs over MAXDATELEN. So it throws an error but passes the varlena string
where the format expects a c string. Of course having to generate a c string
for the format begs the question...

The bug can be triggered trivially with:
postgres=# select repeat(' ',64)::text::date;
ERROR:  invalid input syntax for type date: "   
 
~