Możesz napisać własną funkcję to_date(), ale musisz ją wywołać, używając jej nazwy kwalifikowanej według schematu. (Użyłem schematu „public”, ale nie ma w tym nic specjalnego).
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
Użycie samej nazwy funkcji powoduje wykonanie natywnej funkcji to_date().
select to_date('20130229', 'yyyymmdd');
2013-03-01
Użycie nazwy kwalifikowanej do schematu powoduje wykonanie funkcji zdefiniowanej przez użytkownika.
select public.to_date('20130229', 'yyyymmdd');
ERROR: date/time field value out of range: "20130229"
SQL state: 22008
Wiem, że to nie jest to, czego szukasz. Ale . . .
- To prostsze niż przebudowanie PostgreSQL ze źródeł.
- Naprawianie istniejącego kodu źródłowego SQL i PLPGSQL to proste wyszukiwanie i zastępowanie za pomocą edytora strumieniowego. Jestem przekonany, że nie może się nie udać, o ile naprawdę chcesz każde użycie natywnej to_date() jako public.to_date().
- Natywna funkcja to_date() nadal będzie działać zgodnie z założeniami. Rozszerzenia i inny kod mogą polegać na jego nieco osobliwym zachowaniu. Pomyśl mocno i długo, zanim zmienisz zachowanie funkcji natywnych.
Jednak nowy SQL i PLPGSQL wymagałyby przeglądu. Nie spodziewałbym się, że programiści będą pamiętać o pisaniu public.to_date() za każdym razem. Jeśli używasz kontroli wersji, możesz być w stanie napisać przechwycenie precommit, aby upewnić się, że używana jest tylko public.to_date().
Natywna funkcja to_date() ma zachowanie, którego nie widzę w dokumentacji. Nie tylko możesz zadzwonić do 29 lutego, ale możesz zadzwonić do 345 lutego lub 9999 lutego.
select to_date('201302345', 'yyyymmdd');
2014-01-11
select to_date('2013029999', 'yyyymmdd');
2040-06-17
