Joseph Koshakow <kosh...@gmail.com> writes:
> On Sat, Mar 4, 2023 at 1:56 PM Tom Lane <t...@sss.pgh.pa.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
