Neil Conway <neil.con...@gmail.com> writes:
> *** src/backend/utils/adt/datetime.c 9 May 2010 02:15:59 -0000 1.212
> --- src/backend/utils/adt/datetime.c 1 Aug 2010 23:09:30 -0000
> ***************
> *** 3098,3104 ****
> break;
> case RESERV:
> ! tmask = (DTK_DATE_M ||
> DTK_TIME_M);
> *dtype = val;
> break;
> --- 3098,3104 ----
> break;
> case RESERV:
> ! tmask = (DTK_DATE_M |
> DTK_TIME_M);
> *dtype = val;
> break;
BTW, some digging in the code shows that this line is reached only for
interval input "invalid", which hasn't been accepted for a long time
anyhow:
regression=# select 'invalid'::interval;
ERROR: date/time value "invalid" is no longer supported
However, the mistaken value given to tmask interferes with detecting
other errors, in particular the DTERR_BAD_FORMAT that you ought to get
for specifying conflicting fields. The DTK_DATE_M | DTK_TIME_M value
is intended to say that "invalid" conflicts with any date or time field.
But since the wrong value is assigned, you can do this:
regression=# select '3 day invalid'::interval;
ERROR: date/time value "3 day invalid" is no longer supported
and the syntax error fails to trigger, so that control gets as far as
complaining about the DTK_INVALID type instead. With the fix, you
get the intended behavior:
regression=# select '3 day invalid'::interval;
ERROR: invalid input syntax for type interval: "3 day invalid"
So this is a real bug, though surely one that's awfully far down the
severity scale, to the point that the compiler warning might be judged
more annoying than the actual bug. I'm inclined to fix it in HEAD and
9.0, which are the only branches that anyone's likely to be excited
about building with clang.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
