[
https://issues.apache.org/jira/browse/CALCITE-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824543#comment-17824543
]
Tanner Clary commented on CALCITE-6308:
---------------------------------------
seems like a good initiative, tag me on reviews for individual functions if
you'd like.
> 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)
