Puoi scrivere la tua funzione to_date(), ma devi chiamarla con il suo nome qualificato dallo schema. (Ho usato lo schema "pubblico", ma non c'è niente di speciale in questo.)
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
L'utilizzo del nome della funzione nuda esegue la funzione nativa to_date().
select to_date('20130229', 'yyyymmdd');
2013-03-01
L'utilizzo del nome qualificato dallo schema esegue la funzione definita dall'utente.
select public.to_date('20130229', 'yyyymmdd');
ERROR: date/time field value out of range: "20130229"
SQL state: 22008
So che non è proprio quello che stai cercando. Ma . . .
- È più semplice che ricostruire PostgreSQL dal sorgente.
- Riparare il codice sorgente SQL e PLPGSQL esistente è una semplice ricerca e sostituzione con un editor di streaming. Sono abbastanza sicuro che non possa andare storto, purché tu vuoi davvero ogni utilizzo del nativo to_date() deve essere public.to_date().
- La funzione nativa to_date() continuerà a funzionare come previsto. Estensioni e altro codice potrebbero fare affidamento sul suo comportamento alquanto peculiare. Pensaci bene e a lungo prima di modificare il comportamento delle funzioni native.
Tuttavia, è necessario rivedere il nuovo SQL e PLPGSQL. Non mi aspetto che gli sviluppatori si ricordino di scrivere public.to_date() ogni volta. Se utilizzi il controllo della versione, potresti essere in grado di scrivere un hook di precommit per assicurarti che venga utilizzato solo public.to_date().
La funzione nativa to_date() ha un comportamento che non vedo documentato. Non solo puoi chiamarlo con il 29 febbraio, puoi chiamarlo con il 345 febbraio o 9999 febbraio.
select to_date('201302345', 'yyyymmdd');
2014-01-11
select to_date('2013029999', 'yyyymmdd');
2040-06-17
