आप अपना खुद का to_date() फ़ंक्शन लिख सकते हैं, लेकिन आपको इसे इसके स्कीमा-योग्य नाम से कॉल करना होगा। (मैंने स्कीमा "सार्वजनिक" का उपयोग किया है, लेकिन इसमें कुछ खास नहीं है।)
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() का उपयोग किया जाता है, एक प्री-कमिट हुक लिखने में सक्षम हो सकते हैं।
मूल to_date() फ़ंक्शन में ऐसा व्यवहार होता है जिसे मैं प्रलेखित नहीं देखता। न केवल आप इसे 29 फरवरी से कॉल कर सकते हैं, आप इसे 345 फरवरी, या फरवरी 9999 के साथ भी कॉल कर सकते हैं।
select to_date('201302345', 'yyyymmdd');
2014-01-11
select to_date('2013029999', 'yyyymmdd');
2040-06-17
