Bạn có thể viết hàm to_date () của riêng mình, nhưng bạn phải gọi nó bằng tên đủ điều kiện lược đồ. (Tôi đã sử dụng lược đồ "công khai", nhưng không có gì đặc biệt về điều đó.)
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
Sử dụng tên hàm trần sẽ thực thi hàm to_date () gốc.
select to_date('20130229', 'yyyymmdd');
2013-03-01
Việc sử dụng tên đủ điều kiện của lược đồ sẽ thực thi chức năng do người dùng xác định.
select public.to_date('20130229', 'yyyymmdd');
ERROR: date/time field value out of range: "20130229"
SQL state: 22008
Tôi biết đó không phải là những gì bạn đang tìm kiếm. Nhưng mà . . .
- Nó đơn giản hơn việc xây dựng lại PostgreSQL từ nguồn.
- Sửa mã nguồn SQL và PLPGSQL hiện tại của bạn là một tìm kiếm và thay thế đơn giản bằng một trình chỉnh sửa trực tuyến. Tôi khá chắc rằng điều đó không thể sai, miễn là bạn thực sự muốn mọi việc sử dụng to_date () gốc thành public.to_date ().
- Hàm to_date () gốc sẽ vẫn hoạt động như được thiết kế. Các tiện ích mở rộng và mã khác có thể dựa vào hành vi hơi đặc biệt của nó. Hãy suy nghĩ thật kỹ và thật lâu trước khi bạn thay đổi hoạt động của các hàm gốc.
Tuy nhiên, SQL và PLPGSQL mới sẽ cần được xem xét lại. Tôi sẽ không mong đợi các nhà phát triển luôn nhớ viết public.to_date (). Nếu bạn sử dụng kiểm soát phiên bản, bạn có thể viết một hook gửi trước để đảm bảo rằng chỉ public.to_date () được sử dụng.
Hàm to_date () gốc có hành vi mà tôi không thấy được ghi lại. Bạn không chỉ có thể gọi nó bằng ngày 29 tháng 2, bạn có thể gọi nó bằng ngày 3 tháng 2 năm 345 hoặc tháng 2 năm 9999.
select to_date('201302345', 'yyyymmdd');
2014-01-11
select to_date('2013029999', 'yyyymmdd');
2040-06-17
