独自のto_date（）関数を作成できますが、スキーマ修飾名を使用して呼び出す必要があります。 （私はスキーマ「public」を使用しましたが、それについて特別なことは何もありません。）
create or replace function public.to_date(any_date text, format_string text)
returns date as
$$
select to_date((any_date::date)::text, format_string);
$$
language sql
ベア関数名を使用すると、ネイティブのto_date（）関数が実行されます。
select to_date('20130229', 'yyyymmdd');
2013-03-01
スキーマ修飾名を使用すると、ユーザー定義関数が実行されます。
select public.to_date('20130229', 'yyyymmdd');
ERROR: date/time field value out of range: "20130229"
SQL state: 22008
私はそれがあなたが探しているものではないことを知っています。しかし 。 。 。
- ソースからPostgreSQLを再構築するよりも簡単です。
- 既存のSQLおよびPLPGSQLソースコードの修正は、ストリーミングエディタを使用した簡単な検索と置換です。あなたが本当に望んでいる限り、それは間違いないだろうと私は確信しています。 ネイティブto_date（）を使用するたびにpublic.to_date（）になります。
- ネイティブのto_date（）関数は引き続き設計どおりに機能します。拡張機能やその他のコードは、そのやや独特の動作に依存している可能性があります。ネイティブ関数の動作を変更する前に、よく考えてください。
ただし、新しいSQLとPLPGSQLを確認する必要があります。開発者が毎回public.to_date（）を書くことを覚えているとは思いません。バージョン管理を使用する場合は、precommitフックを記述して、public.to_date（）のみが使用されるようにすることができる場合があります。
ネイティブのto_date（）関数には、文書化されていない動作があります。 2月29日だけでなく、2月345日または2月9999日でも電話をかけることができます。
select to_date('201302345', 'yyyymmdd');
2014-01-11
select to_date('2013029999', 'yyyymmdd');
2040-06-17