मैं एक नलबल कॉलम पर प्राथमिक कुंजी के साथ एक टेबल क्यों बना सकता हूं?

क्योंकि PRIMARY KEY बनाता है शामिल कॉलम NOT NULL स्वचालित रूप से . मैं यहां मैनुअल को उद्धृत करता हूं:

प्राथमिक कुंजी बाधा निर्दिष्ट करती है कि एटेबल के कॉलम या कॉलम में केवल अनन्य (गैर-डुप्लिकेट), गैर-शून्य मान हो सकते हैं। तकनीकी रूप से, PRIMARY KEY केवल UNIQUE . का एक संयोजन है और NOT NULL ।

बोल्ड जोर मेरा।

मैंने यह पुष्टि करने के लिए एक परीक्षण चलाया कि NOT NULL PRIMARY KEY . के संयोजन में पूरी तरह से बेमानी है बाधा (वर्तमान कार्यान्वयन में, संस्करण 13 में सेवानिवृत्त)। NOT NULL बाधा बनी रहती है स्पष्ट NOT NULL . की परवाह किए बिना, PK बाधा को छोड़ने के बाद भी, निर्माण के समय खंड।

CREATE TABLE foo (foo_id int PRIMARY KEY);
ALTER TABLE foo DROP CONSTRAINT foo_pkey;

db=# \d foo
   table »public.foo«
 column |  type   | attribute
--------+---------+-----------
 foo_id | integer | not null    -- stays

db<>यहां बेला करें

समान व्यवहार यदि NULL CREATE TABLE में शामिल है बयान।

यह अभी भी NOT NULL रखने के लिए चोट नहीं पहुंचाएगा कोड रिपॉजिटरी में अनावश्यक रूप से यदि कॉलम को NOT NULL . माना जाता है . यदि आप बाद में PK बाधा को बदलने का निर्णय लेते हैं, तो आप NOT NULL कॉलम को चिह्नित करना भूल सकते हैं। - या क्या यह NOT NULL होना चाहिए था? ।

पोस्टग्रेज TODO विकी में एक आइटम है जो NOT NULL . को डिकूप करने के लिए है पीके बाधा से। तो यह भविष्य के संस्करणों में बदल सकता है:

न्यूल बाधा जानकारी को pg_constraint पर ले जाएं

वर्तमान में NOT NULL बाधाओं को उनके मूल के किसी भी पदनाम के बिना pg_attribute में संग्रहीत किया जाता है, उदा। प्राथमिक कुंजी। एक प्रकट समस्या यह है कि प्राथमिक कुंजी बाधा छोड़ने से न्यूल बाधा पदनाम नहीं हटाया जाता है। एक और मुद्दा यह है कि हमें माता-पिता की टेबल से बच्चों तक प्रचारित करने के लिए संभावित रूप से न्यूल को मजबूर नहीं करना चाहिए, जैसे चेक बाधाएं हैं। (लेकिन फिर क्या प्राथमिक कुंजी छोड़ने से बच्चों पर असर पड़ता है?)

अतिरिक्त प्रश्न का उत्तर

क्या यह बेहतर नहीं होगा यदि यह आत्म-विरोधाभासी CREATE TABLE वहीं पर विफल हो जाए?

जैसा कि ऊपर बताया गया है, यह

foo_id INTEGER NULL PRIMARY KEY

(वर्तमान में) 100% इसके बराबर है:

foo_id INTEGER PRIMARY KEY

चूंकि NULL इस संदर्भ में शोर शब्द के रूप में माना जाता है।
और हम नहीं चाहेंगे कि बाद वाला विफल हो। तो यह कोई विकल्प नहीं है।