Du kan skrive din egen to_date() funktion, men du skal kalde den med dens skema-kvalificerede navn. (Jeg brugte skemaet "offentlig", men der er ikke noget særligt ved 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
Ved at bruge det blotte funktionsnavn udføres den oprindelige to_date()-funktion.
select to_date('20130229', 'yyyymmdd');
2013-03-01
Brug af det skema-kvalificerede navn udfører den brugerdefinerede funktion.
select public.to_date('20130229', 'yyyymmdd');
ERROR: date/time field value out of range: "20130229"
SQL state: 22008
Jeg ved, at det ikke helt er det, du leder efter. Men . . .
- Det er nemmere end at genopbygge PostgreSQL fra kilden.
- Reparering af din eksisterende SQL- og PLPGSQL-kildekode er en simpel søg-og-erstat med en streaming-editor. Jeg er ret sikker på, at det ikke kan gå galt, så længe du virkelig vil hver brug af den oprindelige to_date() skal være public.to_date().
- Den indbyggede to_date()-funktion vil stadig fungere som designet. Udvidelser og anden kode kan stole på dens noget ejendommelige adfærd. Tænk dig grundigt om og længe, før du ændrer adfærden for native funktioner.
Ny SQL og PLPGSQL skulle dog gennemgås. Jeg ville ikke forvente, at udviklere husker at skrive public.to_date() hver gang. Hvis du bruger versionskontrol, kan du muligvis skrive en precommit-hook for at sikre, at kun public.to_date() bruges.
Den native to_date()-funktion har adfærd, som jeg ikke kan se dokumenteret. Ikke alene kan du ringe til den med 29. februar, du kan ringe til den med februar 345 eller februar 9999.
select to_date('201302345', 'yyyymmdd');
2014-01-11
select to_date('2013029999', 'yyyymmdd');
2040-06-17