U kunt uw eigen to_date()-functie schrijven, maar u moet deze aanroepen met zijn schema-gekwalificeerde naam. (Ik gebruikte het schema "public", maar daar is niets bijzonders aan.)
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
Het gebruik van de kale functienaam voert de native to_date() functie uit.
select to_date('20130229', 'yyyymmdd');
2013-03-01
Het gebruik van de voor het schema gekwalificeerde naam voert de door de gebruiker gedefinieerde functie uit.
select public.to_date('20130229', 'yyyymmdd');
ERROR: date/time field value out of range: "20130229"
SQL state: 22008
Ik weet dat dat niet helemaal is wat je zoekt. Maar . . .
- Het is eenvoudiger dan PostgreSQL opnieuw op te bouwen vanaf de broncode.
- Het repareren van uw bestaande SQL- en PLPGSQL-broncode is eenvoudig zoeken en vervangen met een streamingeditor. Ik ben er vrij zeker van dat het niet fout kan gaan, zolang je het maar echt wilt elk gebruik van de native to_date() om public.to_date() te zijn.
- De native to_date()-functie werkt nog steeds zoals ontworpen. Extensies en andere code kunnen afhankelijk zijn van zijn enigszins eigenaardige gedrag. Denk goed na en lang voordat je het gedrag van native functies verandert.
Nieuwe SQL en PLPGSQL zouden echter moeten worden herzien. Ik zou niet verwachten dat ontwikkelaars eraan denken om elke keer public.to_date() te schrijven. Als u versiebeheer gebruikt, kunt u mogelijk een precommit-hook schrijven om ervoor te zorgen dat alleen public.to_date() wordt gebruikt.
De native to_date()-functie heeft gedrag dat ik niet gedocumenteerd zie. Je kunt het niet alleen met 29 februari bellen, je kunt het ook met februari 345 of februari 9999 noemen.
select to_date('201302345', 'yyyymmdd');
2014-01-11
select to_date('2013029999', 'yyyymmdd');
2040-06-17