Thread: Bug in date.c
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: " ~!@" I would be inclined to just go ahead and just call textout which would effectively be pallocing a copy. Is there some reason these functions in particular shouldn't leak memory? I've attached both a patch that does that and a patch that just makes the minimal fix of calling textout when the error is thrown. Alternatively it might be handy to have a custom escape in errmsg format strings for text varlena data. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Attachment
Gregory Stark <stark@enterprisedb.com> 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