Você pode escrever sua própria função to_date(), mas precisa chamá-la com seu nome qualificado pelo esquema. (Eu usei o esquema "público", mas não há nada de especial nisso.)
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
Usar o nome da função simples executa a função nativa to_date().
select to_date('20130229', 'yyyymmdd');
2013-03-01
O uso do nome qualificado pelo esquema executa a função definida pelo usuário.
select public.to_date('20130229', 'yyyymmdd');
ERROR: date/time field value out of range: "20130229"
SQL state: 22008
Eu sei que não é bem isso que você está procurando. Mas . . .
- É mais simples do que reconstruir o PostgreSQL a partir do código-fonte.
- Corrigir seu código-fonte SQL e PLPGSQL existente é uma simples pesquisa e substituição com um editor de streaming. Tenho certeza de que isso não pode dar errado, contanto que você realmente quere cada uso do to_date() nativo seja public.to_date().
- A função nativa to_date() ainda funcionará conforme projetado. Extensões e outros códigos podem depender de seu comportamento um tanto peculiar. Pense muito antes de alterar o comportamento das funções nativas.
No entanto, novos SQL e PLPGSQL precisariam ser revisados. Eu não esperaria que os desenvolvedores se lembrassem de escrever public.to_date() todas as vezes. Se você usar o controle de versão, poderá escrever um gancho de pré-confirmação para garantir que apenas public.to_date() seja usado.
A função nativa to_date() tem um comportamento que não vejo documentado. Não só você pode chamá-lo com 29 de fevereiro, você pode chamá-lo com fevereiro 345 ou fevereiro 9999.
select to_date('201302345', 'yyyymmdd');
2014-01-11
select to_date('2013029999', 'yyyymmdd');
2040-06-17
