Re: Date-time extraneous fields with reserved keywords

On Sat, Mar 4, 2023 at 1:56 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> I think we should tread very carefully about disallowing inputs that
> have been considered acceptable for 25 years. I agree with disallowing
> numeric fields along with 'epoch' and 'infinity', but for example
> this seems perfectly useful and sensible:
>
> # select timestamptz 'today 12:34';
> timestamptz
> ------------------------
> 2023-03-04 12:34:00-05
> (1 row)

Yeah, that makes sense. I'll leave it as is with
the explicit case for 'epoch', 'infinity', and
'-infinity'.

> Why do you want to skip ValidateDate in some cases? If we've not
> had to do that before, I don't see why it's a good idea now.

This goes back to the abstraction break of
setting tmask without updating tm. Certain
validations will check that if a field is set in
fmask (which is an accumulation of tmask from
every iteration) then it's value in tm is valid.
For example:

if (fmask & DTK_M(YEAR))
{
// ...
else
{
/* there is no year zero in AD/BC notation */
if (tm->tm_year <= 0)
return DTERR_FIELD_OVERFLOW;
}
}

As far as I can tell dtype always equals DTK_DATE
except when the timestamp/date is 'epoch',
'infinity', '-infinity', and none of the
validations apply to those date/timestamps.
Though, I think you're right this is probably
not a good idea. I'll try and brainstorm a
different approach, unless you have some ideas.