Calls to PARSEDATE or PARSETIME which have a timestamp value as the first argument are now pushed as CONVERTs (otherwise they are pushed as regular PARSEDATEs or PARSETIMEs respectively).
Description of problem:
A regression was found for an enhancement originally introduced in 6.3.4.
According to TEIID-4543, parsing a date or time from a string column using the PARSEDATE or PARSETIME functions should be pushed as simple cast in case the format string is the standard value ('yyyy-MM-dd' and 'hh:mm:ss' respectively).
However, running e.g.
SELECT IntKey FROM Source.SmallA WHERE PARSEDATE(StringKey, 'yyyy-MM-dd') = {d'2016-12-19'}
with 6.4 ER2 shows the following in the query plan:
AccessNode(0) output=[Source.smalla.intkey] SELECT g_0.intkey AS c_0 FROM Source.smalla AS g_0 WHERE convert(parsetimestamp(g_0.stringkey, 'yyyy-MM-dd'), date) = {d'2016-12-19'} LIMIT 100
i.e. there is still the call to parsetimestamp function.
Description of problem: A regression was found for an enhancement originally introduced in 6.3.4. According to TEIID-4543, parsing a date or time from a string column using the PARSEDATE or PARSETIME functions should be pushed as simple cast in case the format string is the standard value ('yyyy-MM-dd' and 'hh:mm:ss' respectively). However, running e.g. SELECT IntKey FROM Source.SmallA WHERE PARSEDATE(StringKey, 'yyyy-MM-dd') = {d'2016-12-19'} with 6.4 ER2 shows the following in the query plan: AccessNode(0) output=[Source.smalla.intkey] SELECT g_0.intkey AS c_0 FROM Source.smalla AS g_0 WHERE convert(parsetimestamp(g_0.stringkey, 'yyyy-MM-dd'), date) = {d'2016-12-19'} LIMIT 100 i.e. there is still the call to parsetimestamp function.