Postgresql-एक वर्चर कॉलम के आकार को बदलें




varchar alter-table (6)

मेरे पास वास्तव में बड़ी तालिका (लगभग 30 लाख पंक्तियों) पर ALTER TABLE कमांड के बारे में एक प्रश्न है। इसके स्तंभों में से एक varchar(255) और मैं इसे एक varchar(40) आकार बदलना चाहता हूं। असल में, मैं निम्न आदेश चलाकर अपना कॉलम बदलना चाहता हूं:

ALTER TABLE mytable ALTER COLUMN mycolumn TYPE varchar(40);

अगर प्रक्रिया बहुत लंबी है तो मुझे कोई समस्या नहीं है, लेकिन ऐसा लगता है कि मेरी तालिका ALTER TABLE कमांड के दौरान और अधिक पठनीय नहीं है। क्या कोई चालाक तरीका है? शायद एक नया कॉलम जोड़ें, पुराने कॉलम से मूल्य कॉपी करें, पुराने कॉलम को छोड़ दें और आखिरकार नया नाम बदलें?

किसी भी सुराग की सराहना की जाएगी! अग्रिम में धन्यवाद,

नोट: मैं PostgreSQL 9.0 का उपयोग करता हूं।


PostgreSQL 9.1 में एक आसान तरीका है

http://www.postgresql.org/message-id/[email protected]

CREATE TABLE foog(a varchar(10));

ALTER TABLE foog ALTER COLUMN a TYPE varchar(30);

postgres=# \d foog

 Table "public.foog"
 Column |         Type          | Modifiers
--------+-----------------------+-----------
 a      | character varying(30) |

ग्रेग स्मिथ द्वारा वर्णित पृष्ठ का कैश यहां दिया गया है। यदि यह भी मर जाता है, तो परिवर्तन कथन इस तरह दिखता है:

UPDATE pg_attribute SET atttypmod = 35+4
WHERE attrelid = 'TABLE1'::regclass
AND attname = 'COL1';

जहां आपकी तालिका TABLE1 है, कॉलम COL1 है और आप इसे 35 वर्णों में सेट करना चाहते हैं (लिंक के अनुसार विरासत उद्देश्यों के लिए +4 आवश्यक है, संभवतः टिप्पणियों में एएच द्वारा संदर्भित ओवरहेड)।


नए कॉलम को जोड़ना और पुराने के साथ नए काम को बदलना, redshift postgresql पर, अधिक जानकारी के लिए इस लिंक को देखें https://gist.github.com/mmasashi/7107430

BEGIN;
LOCK users;
ALTER TABLE users ADD COLUMN name_new varchar(512) DEFAULT NULL;
UPDATE users SET name_new = name;
ALTER TABLE users DROP name;
ALTER TABLE users RENAME name_new TO name;
END;

मुझे 32 से 8 तक एक वर्चर को छीनने और ERROR: value too long for type character varying(8) प्राप्त करने की कोशिश करने में एक ही समस्या का सामना करना पड़ रहा था ERROR: value too long for type character varying(8) । मैं जितना संभव हो सके एसक्यूएल के करीब रहना चाहता हूं क्योंकि मैं एक स्व-निर्मित जेपीए जैसी संरचना का उपयोग कर रहा हूं जिसे हमें ग्राहक के विकल्पों के अनुसार अलग-अलग डीबीएमएस पर स्विच करना पड़ सकता है (PostgreSQL डिफ़ॉल्ट है)। इसलिए, मैं सिस्टम टेबल को बदलने की चाल का उपयोग नहीं करना चाहता हूं।

मैंने ALTER TABLE में USING स्टेटमेंट का USING समाप्त कर दिया:

ALTER TABLE "MY_TABLE" ALTER COLUMN "MyColumn" TYPE varchar(8)
USING substr("MyColumn", 1, 8)

यदि टेबल को किसी अन्य प्रोग्राम द्वारा एक्सेस किया जा रहा है या तालिका को अनुक्रमित किया गया है तो मैंने वास्तव में प्रभाव नहीं माना है। मुझे लगता है कि पोस्टग्रेस स्वचालित रूप से उस तरह का करता है?


यदि आप लेनदेन में बदलाव डालते हैं तो तालिका को लॉक नहीं किया जाना चाहिए:

BEGIN;
  ALTER TABLE "public"."mytable" ALTER COLUMN "mycolumn" TYPE varchar(40);
COMMIT;

यह मेरे लिए 400k पंक्तियों से अधिक तालिका के साथ तेजी से चमक रहा है, कुछ सेकंड के लिए काम किया।


डेटा बदलने के बिना PostgreSQL तालिका में कॉलम का आकार बदलने के लिए इसे कैसे करें इसका विवरण है। आपको डेटाबेस कैटलॉग डेटा हैक करना होगा। आधिकारिक रूप से ऐसा करने का एकमात्र तरीका वैकल्पिक तालिका के साथ है, और जैसा कि आपने ध्यान दिया है कि परिवर्तन लॉक हो जाएगा और पूरे टेबल को फिर से लिखने के दौरान फिर से लिख देगा।

सुनिश्चित करें कि आप इसे बदलने से पहले दस्तावेज़ों के कैरेक्टर प्रकार अनुभाग को पढ़ लें। अजीब मामलों के सभी प्रकार यहां से अवगत होंगे। जब पंक्तियों में मान संग्रहीत होते हैं तो लम्बाई जांच की जाती है। यदि आप वहां कम सीमा हैक करते हैं, तो मौजूदा मानों के आकार को कम नहीं करेगा। आप पंक्तियों की तलाश में पूरी तालिका पर एक स्कैन करना बुद्धिमान होगा जहां परिवर्तन की अवधि के बाद फ़ील्ड की लंबाई> 40 वर्ण हैं। आपको यह समझने की आवश्यकता होगी कि मैन्युअल रूप से उनको कैसे मिटाया जाए - ताकि आप केवल कुछ लोगों को ओवरसीज पर वापस कर सकें - क्योंकि अगर कोई उस पंक्ति पर कुछ भी अपडेट करने का प्रयास करता है तो यह अब इसे बहुत बड़ा अस्वीकार कर देगा, बिंदु पर यह पंक्ति के नए संस्करण को स्टोर करने के लिए चला जाता है। उपयोगकर्ता के लिए Hilarity ensues।

VARCHAR एक भयानक प्रकार है जो पोस्टग्रेएसक्यूएल में केवल SQL मानक के अपने संबंधित भयानक हिस्से का अनुपालन करने के लिए मौजूद है। यदि आपको बहु-डेटाबेस संगतता की परवाह नहीं है, तो अपने डेटा को टेक्स्ट के रूप में संग्रहीत करने पर विचार करें और इसकी लंबाई को सीमित करने के लिए बाधा जोड़ें। इस तालिका के बिना आप बाधाओं को पुनर्स्थापित कर सकते हैं / समस्या को फिर से लिख सकते हैं, और वे कमजोर लंबाई की जांच से अधिक अखंडता जांच कर सकते हैं।





alter-table