Можете да напишете своя собствена функция to_date(), но трябва да я извикате с нейното квалифицирано от схема име. (Използвах схемата „public“, но в това няма нищо особено.)
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
Използването на голото име на функция изпълнява основната функция to_date().
select to_date('20130229', 'yyyymmdd');
2013-03-01
Използването на квалифицираното от схемата име изпълнява дефинираната от потребителя функция.
select public.to_date('20130229', 'yyyymmdd');
ERROR: date/time field value out of range: "20130229"
SQL state: 22008
Знам, че това не е точно това, което търсите. Но . . .
- По-лесно е от повторното изграждане на PostgreSQL от източника.
- Коригирането на вашия съществуващ изходен код на SQL и PLPGSQL е просто търсене и замяна с редактор за поточно предаване. Почти съм сигурен, че това не може да се обърка, стига наистина да искате всяко използване на естествения to_date() да бъде public.to_date().
- Нативната функция to_date() ще продължи да работи, както е проектирана. Разширенията и друг код може да разчитат на донякъде странното му поведение. Мислете добре и дълго, преди да промените поведението на естествените функции.
Новите SQL и PLPGSQL обаче ще трябва да бъдат прегледани. Не бих очаквал разработчиците да се сещат да пишат public.to_date() всеки път. Ако използвате контрол на версиите, може да сте в състояние да напишете прекомит кука, за да сте сигурни, че се използва само public.to_date().
Функцията native to_date() има поведение, което не виждам документирано. Не само можете да го наречете с 29 февруари, можете да го наречете с 345 февруари или 9999 февруари.
select to_date('201302345', 'yyyymmdd');
2014-01-11
select to_date('2013029999', 'yyyymmdd');
2040-06-17
