Simplify predicates involving year function

[ebyhr]

Description

Fixes #14078

Release notes

(x) Release notes are required, with the following suggested text:

# General
* Improve performance of queries that contain predicates involving `year` function. ({issue}`14078`)

[ebyhr]

Addressed comments.

[findinpath]

CI hit #13633

[findepi]

Am I correct it's not possible to normalize year() to date_trunc('year' or the other way around?

[findepi]

If the value is known to be long (or int), let the caller do the conversion.

[findepi]

.with(firstDayOfYear()) seems redundant

[findepi]

Why not LocalDateTime.of(year, 1, 1, 0, 0)?

[findepi]

LocalDateTime.of(year, 1, 1, 0, 0)?

[findepi]

Suggested change

	if (argumentType != DATE && !(argumentType instanceof TimestampType)) {
	// e.g. year(INTERVAL) not handled here
	return expression;
	}

[findepi]

Not sure I understand the comment.

per the comment below (// if types do no match, this cannot be a comparison function) we didn't verify yet the call represents a comparison, so we don't know anything about relation between firstArgument and secondArgument

let's remove the comment

[findepi]

LocalTime.MIN looks better in this context or perhaps

int year = toIntExact((Long) constant.getValue());
ZonedDateTime periodStart = ZonedDateTime.of(year, 1, 1, 0, 0, 0, 0, UTC);

[findepi]

right-open ranges are easier to construct and work with, see unwrapTimestampTzToDateCast

in fact, there is high overlap between that method and the new one, opportunity for re-use

[findepi]

The TODO got removed, but this still reads .isNotFullyPushedDown(); instead of .isFullyPushedDown().
It looks like the test asserts that the functionality doesn't work as intended.

[findepi]

btw #16017

[ebyhr]

I accidentally deleted the branch. Sent a new PR #16106