Puede escribir su propia función to_date(), pero debe llamarla con su nombre calificado de esquema. (Usé el esquema "público", pero no tiene nada de especial).
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
El uso del nombre de la función simple ejecuta la función nativa to_date().
select to_date('20130229', 'yyyymmdd');
2013-03-01
El uso del nombre calificado de esquema ejecuta la función definida por el usuario.
select public.to_date('20130229', 'yyyymmdd');
ERROR: date/time field value out of range: "20130229"
SQL state: 22008
Sé que eso no es exactamente lo que estás buscando. Pero . . .
- Es más simple que reconstruir PostgreSQL desde la fuente.
- Reparar su código fuente SQL y PLPGSQL existente es una simple búsqueda y reemplazo con un editor de transmisión. Estoy bastante seguro de que no puede salir mal, siempre y cuando realmente quieras cada uso del to_date() nativo para ser public.to_date().
- La función nativa to_date() seguirá funcionando como se diseñó. Las extensiones y otros códigos pueden depender de su comportamiento un tanto peculiar. Piense bien y mucho antes de cambiar el comportamiento de las funciones nativas.
Sin embargo, sería necesario revisar el nuevo SQL y PLPGSQL. No esperaría que los desarrolladores recordaran escribir public.to_date() cada vez. Si usa el control de versiones, es posible que pueda escribir un gancho de confirmación previa para asegurarse de que solo se use public.to_date().
La función nativa to_date() tiene un comportamiento que no veo documentado. No solo puede llamarlo el 29 de febrero, puede llamarlo el 345 de febrero o el 9999 de febrero.
select to_date('201302345', 'yyyymmdd');
2014-01-11
select to_date('2013029999', 'yyyymmdd');
2040-06-17
