[ https://issues.apache.org/jira/browse/CALCITE-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824893#comment-17824893 ]
Caican Cai commented on CALCITE-6308: ------------------------------------- [~jduong] Hello, I also found this and I'm working on this part > Add PostgreSQL functions up to PostgreSQL v14 > --------------------------------------------- > > Key: CALCITE-6308 > URL: https://issues.apache.org/jira/browse/CALCITE-6308 > Project: Calcite > Issue Type: Improvement > Components: core > Reporter: James Duong > Priority: Minor > > Support the following PostgreSQL functions for parity with PostgreSQL 14: > * REGEXP_LIKE > ** The Spark version of this is being implemented in CALCITE-6278 > ** The PostgreSQL version requires supporting a 3-arg version that takes in > flags. > * REGEXP_REPLACE > ** There is an existing implementation. > ** PostgreSQL requires supporting an optional extra flags argument > * DATE_PART > ** PostgreSQL and Redshift let the date_part parameter be a string instead > of a just an enum-like identifier (eg DATE_PART('year', ...) and > DATE_PART(year, ...) are both supported. > ** SQL Server does not support using a string here. > * LOG > ** We have the BigQuery implementation which has a 1-arg overload that uses > base e (ln), and a 2-arg overload which is LOG(value, base) > ** PostgreSQL's 1-arg version uses base 10 and the 2-arg overload has the > order reversed – LOG(base, value) > * POW > ** Our existing implementation always returns double. > ** PostgreSQL allows returning a numeric instead of a double when inputs are > numeric. Not sure if this makes sense though. > * RANDOM > ** This is an alias for RAND(), except it should not support passing in a > seed. > * TO_CHAR > * TO_DATE > * TO_TIMESTAMP > ** PostgreSQL supports different format strings than the version we have > implemented. > -- This message was sent by Atlassian Jira (v8.20.10#820010)