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