On Thu, 20 Oct 2022 at 20:45, Erik Rijkers <er@xs4all.nl> wrote:
> Hi,
>
> I noticed that
> select date_part('millennium', now()); --> 3
>
> will execute also, unperturbed, in this form:
> select date_part('millennium xxxxx', now()); --> 3
>
> By the same token
>
> select extract(millennium from now()) --> 3
> select extract(millenniumxxxxxxxxx from now()) --> 3
>
> This laxness occurs in all releases, and with 'millennium',
> 'millisecond', and 'microsecond' (at least).
>
> Even though it's not likely to cause much real-life headaches, and I
> hesitate to call it a real bug, perhaps it would be better if it could
> be a bit stricter.
>
According to the documentation [1], the extract() only has some field names,
however, the code use strncmp() to compare the units and tokens.
int
DecodeUnits(int field, char *lowtoken, int *val)
{
int type;
const datetkn *tp;
tp = deltacache[field];
/* use strncmp so that we match truncated tokens */ <---- here
if (tp == NULL || strncmp(lowtoken, tp->token, TOKMAXLEN) != 0)
{
tp = datebsearch(lowtoken, deltatktbl, szdeltatktbl);
}
if (tp == NULL)
{
type = UNKNOWN_FIELD;
*val = 0;
}
else
{
deltacache[field] = tp;
type = tp->type;
*val = tp->value;
}
return type;
}
This is convenient for field names such as millennium and millenniums,
however it also valid for millenniumxxxxxxxxxxxx, which is looks strange.
Maybe we should document this. I'd be inclined to change the code to
match the certain valid field names.
Any thoughts?
[1] https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-EXTRACT
--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.
