समाधान
संभवतः, समाधान ऑपरेटर को स्कीमा-योग्य बनाना है:
SELECT *
FROM test
WHERE tagged OPERATOR([email protected]>) '{11}'::int2[]
ORDER BY id
LIMIT 100;क्यों?
यह संचालक समाधान की समस्या है (प्रकार संकल्प और कास्ट संदर्भ के संयोजन में)।
मानक पोस्टग्रेज में, केवल एक ही उम्मीदवार ऑपरेटर होता है anyarray @> anyarray , वही आप चाहते हैं।
यदि आपने अतिरिक्त मॉड्यूल इंटरएरे . स्थापित नहीं किया होता तो आपका सेटअप ठीक काम करता (मेरी धारणा), जो integer[] @> integer[] के लिए एक और ऑपरेटर प्रदान करता है ।
इसलिए, दूसरा उपाय यह होगा कि integer[] . का उपयोग किया जाए इसके बजाय और gin__int_ops . के साथ GIN अनुक्रमणिका रखें ऑपरेटर वर्ग। या कोशिश करें (इंटररे के लिए डिफ़ॉल्ट) gist__int_ops अनुक्रमणिका। या तो तेज़ हो सकता है, लेकिन दोनों NULL मानों की अनुमति नहीं देते हैं।
या आप intarray का नाम बदल सकते हैं ऑपरेटर @> स्पष्ट करना। (मैं ऐसा नहीं करूंगा। अपग्रेड और पोर्टेबिलिटी की समस्याएं आती हैं।)
integer[] . प्रकार के कम से कम एक ऑपरेंड वाले व्यंजकों के लिए , पोस्टग्रेज जानता है कि किस ऑपरेटर को चुनना है:इंटररे ऑपरेटर। लेकिन तब सूचकांक लागू नहीं होता , क्योंकि इंटररे ऑपरेटर केवल integer . पर काम करता है (int4 ) नहीं int2 . और इंडेक्स सख्ती से ऑपरेटरों के लिए बाध्य हैं:
- क्या PostgreSQL सरणी स्तंभों को अनुक्रमित कर सकता है?
- एक ही कॉलम पर दो अलग-अलग प्रकार के इंडेक्स की उपस्थिति में पोस्टग्रेएसक्यूएल व्यवहार
लेकिन int2[] @> int2[] . के लिए , Postgres सबसे अच्छा ऑपरेटर तय करने में असमर्थ है। दोनों समान रूप से लागू प्रतीत होते हैं। चूंकि डिफ़ॉल्ट ऑपरेटर pg_catalog . में प्रदान किया जाता है स्कीमा और इंटररे ऑपरेटर public . में प्रदान किया जाता है स्कीमा (डिफ़ॉल्ट रूप से - या जहाँ भी आपने एक्सटेंशन स्थापित किया है), आप OPERATOR() के साथ ऑपरेटर को स्कीमा-योग्य बनाकर पहेली को हल करने में मदद कर सकते हैं। निर्माण। संबंधित:
- तत्वों के क्रम को अनदेखा करते हुए समानता के लिए सरणियों की तुलना करें
आपको जो त्रुटि संदेश मिलता है वह थोड़ा भ्रामक है। लेकिन अगर आप बारीकी से देखें, तो एक HINT है लाइन जोड़ी गई जो सही दिशा में संकेत (टाडा!):
ERROR: operator is not unique: smallint[] @> smallint[] LINE 1: SELECT NULL::int2[] @> NULL::int2[] ^ HINT: Could not choose a best candidate operator. You might need to add explicit type casts.
आप @> . के लिए मौजूदा ऑपरेटर उम्मीदवारों की जांच कर सकते हैं साथ:
SELECT o.oid, *, oprleft::regtype, oprright::regtype, n.nspname
FROM pg_operator o
JOIN pg_namespace n ON n.oid = o.oprnamespace
WHERE oprname = '@>';
एक अन्य वैकल्पिक समाधान अस्थायी रूप से (!) एक अलग search_path सेट करना होगा, इसलिए केवल वांछित ऑपरेटर पाया जाता है। उसी लेन-देन में:
SET LOCAL search_path = pg_catalog;
SELECT ...
लेकिन फिर आपको क्वेरी में सभी तालिकाओं को स्कीमा-योग्य बनाना होगा।
कास्ट संदर्भ के बारे में:
- तिथियों की श्रृंखला उत्पन्न करें - इनपुट के रूप में दिनांक प्रकार का उपयोग करके
आप कर सकते थे castcontext बदलें का int2 -> int4 . लेकिन मैं इसके खिलाफ दृढ़ता से सलाह देता हूं। बहुत अधिक संभावित दुष्प्रभाव:
- क्या postgresql 9.3 डेटा प्रकार डालने का कोई तरीका है ताकि यह केवल एक पक्ष को प्रभावित कर सके
