Sie können Ihre eigene to_date()-Funktion schreiben, aber Sie müssen sie mit ihrem Schema-qualifizierten Namen aufrufen. (Ich habe das Schema "public" verwendet, aber daran ist nichts Besonderes.)
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
Die Verwendung des bloßen Funktionsnamens führt die native Funktion to_date() aus.
select to_date('20130229', 'yyyymmdd');
2013-03-01
Die Verwendung des Schema-qualifizierten Namens führt die benutzerdefinierte Funktion aus.
select public.to_date('20130229', 'yyyymmdd');
ERROR: date/time field value out of range: "20130229"
SQL state: 22008
Ich weiß, das ist nicht ganz das, wonach du suchst. Aber . . .
- Es ist einfacher, als PostgreSQL aus dem Quellcode neu zu erstellen.
- Das Korrigieren Ihres vorhandenen SQL- und PLPGSQL-Quellcodes ist ein einfaches Suchen und Ersetzen mit einem Streaming-Editor. Ich bin mir ziemlich sicher, dass das nicht schiefgehen kann, solange Sie es wirklich wollen jede Verwendung des nativen to_date() zu public.to_date().
- Die native to_date()-Funktion funktioniert weiterhin wie vorgesehen. Erweiterungen und anderer Code können sich auf sein etwas eigenartiges Verhalten verlassen. Denken Sie gründlich und lange nach, bevor Sie das Verhalten nativer Funktionen ändern.
New SQL und PLPGSQL müssten jedoch überprüft werden. Ich würde nicht erwarten, dass Entwickler daran denken, jedes Mal public.to_date() zu schreiben. Wenn Sie die Versionskontrolle verwenden, können Sie möglicherweise einen Precommit-Hook schreiben, um sicherzustellen, dass nur public.to_date() verwendet wird.
Die native Funktion to_date() hat ein Verhalten, das ich nicht dokumentiert sehe. Sie können es nicht nur mit dem 29. Februar nennen, sondern auch mit dem 345. Februar oder dem 9999. Februar.
select to_date('201302345', 'yyyymmdd');
2014-01-11
select to_date('2013029999', 'yyyymmdd');
2040-06-17
