Bug in date.c

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Bug in date.c
Date: 2007-06-02 10:48:54
Message-ID: 87k5um638p.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


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.

Attachment Content-Type Size
date.c.patch.gz application/octet-stream 839 bytes
date-minimal.c.patch.gz application/octet-stream 623 bytes

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Andrew Dunstan 2007-06-02 12:30:58 Re: [PATCHES] build/install xml2 when configured with libxml
Previous Message Greg Smith 2007-06-02 05:51:13 Re: COPY-able csv log outputs