Re: Upcoming 8.0.2 Release - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Upcoming 8.0.2 Release
Date
Msg-id 3250.1111777728@sss.pgh.pa.us
Whole thread Raw
In response to Re: Upcoming 8.0.2 Release  (Karel Zak <zakkr@zf.jcu.cz>)
Responses Re: Upcoming 8.0.2 Release  (Karel Zak <zakkr@zf.jcu.cz>)
List pgsql-hackers
Karel Zak <zakkr@zf.jcu.cz> writes:
> On Fri, 2005-03-25 at 03:29 -0500, Tom Lane wrote:
>> I intend to look at that tomorrow.  Meanwhile, have you got a fix
>> for bug#1500?
>> http://archives.postgresql.org/pgsql-bugs/2005-02/msg00226.php

> Sorry. Not yet. I haven't time today. Maybe next week :-(

I looked at this and found the problem is that dch_date() isn't
defending itself against the possibility that tm->tm_mon is zero,
as it well might be for an interval.  What do you think about
just adding
       case DCH_MONTH:
+           if (!tm->tm_mon)
+               return 0;           strcpy(workbuff, months_full[tm->tm_mon - 1]);           sprintf(inout, "%*s",
S_FM(suf)? 0 : -9, str_toupper(workbuff));           if (S_FM(suf))               return strlen(p_inout) - 1;
else              return 8;
 

and similarly in each of the other case arms that use tm_mon?
This would case "MON" to convert to a null string for intervals,
which is probably as good as we can do.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_dump issue : Cannot drop a non-existent(?) trigger
Next
From: Lyubomir Petrov
Date:
Subject: Bug 1500