Du kan skriva din egen to_date()-funktion, men du måste kalla den med dess schemakvalificerade namn. (Jag använde schemat "public", men det är inget speciellt med det.)
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
Genom att använda det blotta funktionsnamnet körs den ursprungliga to_date()-funktionen.
select to_date('20130229', 'yyyymmdd');
2013-03-01
Genom att använda det schemakvalificerade namnet körs den användardefinierade funktionen.
select public.to_date('20130229', 'yyyymmdd');
ERROR: date/time field value out of range: "20130229"
SQL state: 22008
Jag vet att det inte är riktigt vad du letar efter. Men . . .
- Det är enklare än att bygga om PostgreSQL från källan.
- Att fixa din befintliga SQL- och PLPGSQL-källkod är en enkel sök-och-ersätt med en strömningsredigerare. Jag är ganska säker på att det inte kan gå fel, så länge du verkligen vill varje användning av den ursprungliga to_date() ska vara public.to_date().
- Den inbyggda to_date()-funktionen kommer fortfarande att fungera som den är designad. Tillägg och annan kod kan förlita sig på dess något märkliga beteende. Tänk hårt och länge innan du ändrar beteendet hos inhemska funktioner.
Ny SQL och PLPGSQL skulle dock behöva ses över. Jag skulle inte förvänta mig att utvecklare skulle komma ihåg att skriva public.to_date() varje gång. Om du använder versionskontroll kan du kanske skriva en precommit-hook för att säkerställa att endast public.to_date() används.
Funktionen to_date() har ett beteende som jag inte kan se dokumenterat. Du kan inte bara ringa det med 29 februari, du kan ringa det med februari 345 eller februari 9999.
select to_date('201302345', 'yyyymmdd');
2014-01-11
select to_date('2013029999', 'yyyymmdd');
2040-06-17