Re: Date-time extraneous fields with reserved keywords

Joseph Koshakow <koshy44(at)gmail(dot)com> writes:
> On Sat, Mar 4, 2023 at 1:56 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.

Ah. Another way could be to fill tm with something that would
satisfy ValidateDate, but that seems pretty silly.

> 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.

Right. So really we ought to move the ValidateDate call as
well as the next half-dozen lines about "mer" down into
the subsequent "do additional checking" stanza. It's all
only relevant to normal date specs.

BTW, looking at the set of RESERV tokens in datetktbl[],
it looks to me like this change renders the final "default:"
case unreachable, so probably we could just make that an error.

regards, tom lane