2010-07-14 15 views
23

मुझे पोस्टग्रे में वैकल्पिक तालिका के साथ एक समस्या है। मैं वर्चर कॉलम का आकार बदलना चाहता हूं। जब मैं ऐसा करने का प्रयास करता हूं, तो यह कहता है कि दृश्य उस कॉलम पर निर्भर है। मैं दृश्य को छोड़ नहीं सकता क्योंकि कुछ और इस पर निर्भर है। क्या सब कुछ छोड़ने और फिर से इसे फिर से बनाने के अलावा कोई और तरीका है?पोस्टग्रेस के साथ समस्या वैकल्पिक तालिका

मुझे अभी एक विकल्प मिला है, जो दृश्य से जुड़ने वाली तालिका को हटाना है, जब मैं लौटा कॉलम नहीं बदलूंगा, तो मैं ऐसा कर सकता हूं। लेकिन फिर भी, मुझे और अधिक विचार बदलने की आवश्यकता होगी। क्या कुछ भी नहीं है मैं कैसे कह सकता हूं कि इसे स्थगित कर दिया जाना चाहिए और प्रतिबद्धता के साथ जांच की जानी चाहिए?

+1

दृश्य क्वेरी की प्रतिलिपि बनाएँ और इसे हटाएं और तालिका – TaherT

उत्तर

15

मैंने इस समस्या में भाग लिया है और इसके आसपास कोई रास्ता नहीं मिल सका। दुर्भाग्यवश, जैसा कि मैं सबसे अच्छा कह सकता हूं, किसी को विचार छोड़ना चाहिए, कॉलम प्रकार को अंतर्निहित तालिका में बदलना चाहिए, और फिर दृश्यों को फिर से बनाना चाहिए। यह पूरी तरह से एक लेनदेन में हो सकता है।

बाधा स्थगित इस समस्या पर लागू नहीं होता है। दूसरे शब्दों में, SET CONSTRAINTS ALL DEFERRED पर भी इस सीमा पर कोई प्रभाव नहीं पड़ता है। विशिष्ट होने के लिए, बाधा अवरोध स्थिरता जांच पर लागू नहीं होता है जो ERROR: cannot alter type of a column used by a view or rule प्रिंट करता है जब कोई दृश्य के अंतर्गत कॉलम के प्रकार को बदलने की कोशिश करता है।

4

मैं आज इस समस्या में भाग गया और दृश्य को छोड़ने और पुनर्निर्माण से बचने के लिए चारों ओर एक काम पाया। मैं सिर्फ अपना दृश्य नहीं छोड़ सकता क्योंकि यह एक मास्टर व्यू है जिसमें इसके ऊपर बनाए गए कई निर्भर दृश्य हैं। ड्रॉप कैस्केड में पुनर्निर्माण स्क्रिप्ट होने के बाद और फिर मेरे सभी दृश्यों को फिर से बनाएं, यह एक काम है।

मैं अपमानजनक कॉलम के लिए डमी मान का उपयोग करने के लिए अपने मास्टर दृश्य को बदलता हूं, तालिका में कॉलम बदलता हूं, और मेरे दृश्य को वापस कॉलम पर स्विच करता हूं। इस तरह एक सेटअप का उपयोग करना: आप एक डमी मान का उपयोग करने master_view बदलते हैं तो

ERROR: cannot alter type of a column used by a view or rule 
DETAIL: rule _RETURN on view master_view depends on column "base_table_field1" 

:

ALTER TABLE base_table ALTER COLUMN base_table_field1 TYPE numeric(10,6); 

में आपको यह त्रुटि होगा:

CREATE TABLE base_table 
(
    base_table_id integer, 
    base_table_field1 numeric(10,4) 
); 

CREATE OR REPLACE VIEW master_view AS 
    SELECT 
    base_table_id AS id, 
    (base_table_field1 * .01)::numeric AS field1 
    FROM base_table; 

CREATE OR REPLACE VIEW dependent_view AS 
    SELECT 
    id AS dependent_id, 
    field1 AS dependent_field1 
    FROM master_view; 

इस तरह base_table_field1 प्रकार बदलने के लिए कोशिश कर रहा है इस तरह के कॉलम के लिए:

CREATE OR REPLACE VIEW master_view AS 
    SELECT 
    base_table_id AS id, 
    0.9999 AS field1 
    FROM base_table; 

फिर अपने बदलने चलाएँ:

ALTER TABLE base_table ALTER COLUMN base_table_field1 TYPE numeric(10,6); 

और आपके विचार वापस स्विच:

CREATE OR REPLACE VIEW master_view AS 
    SELECT 
    base_table_id AS id, 
    (base_table_field1 * .01)::numeric AS field1 
    FROM base_table; 

यह सब पर निर्भर करता है कि क्या आपका master_view एक स्पष्ट प्रकार है कि परिवर्तन नहीं करता है। चूंकि मेरा VIEW '(base_table_field1 * .01) :: numeric AS field1' का उपयोग करता है, लेकिन यह 'base_table_field1 AS field1' नहीं होगा क्योंकि कॉलम प्रकार बदलता है। यह दृष्टिकोण मेरे जैसे कुछ मामलों में मदद कर सकता है।

+4

में परिवर्तन करें, यह दृश्य को छोड़ने, तालिका को बदलने और फिर से दृश्य बनाने से बेहतर कैसे है? मुझे लगता है कि दृश्य के डीडीएल को देखने और कॉलम के उदाहरण ढूंढने के साथ यह बदतर है। जब आप गिर रहे हैं, तो आपको मूल दृश्य के डीडीएल की एक प्रति रखना है, ताकि आप इसे फिर से बना सकें। – ADTC

+3

दृश्य को छोड़ने से बेहतर कैसे है? पहली पंक्ति ... "यह एक मास्टर व्यू है जिसमें इसके ऊपर बनाए गए कई निर्भर दृश्य हैं।" यही है, ड्रॉप उन आश्रित विचारों के साथ-साथ कैस्केड भी करता है। –

7

आप मैदान के प्रकार, लेकिन सिर्फ यह के आकार को बदलने की जरूरत नहीं है, इस दृष्टिकोण से काम करना चाहिए:

इन तालिकाओं के साथ शुरू:

CREATE TABLE foo (id integer primary key, names varchar(10)); 
CREATE VIEW voo AS (SELECT id, names FROM foo); 

\d foo और \d voo दोनों 10 के रूप में लंबाई दिखाने:

id  | integer    | not null 
names | character varying(10) | 

अबमें से 20 लंबाई को बदलनेतालिका:

UPDATE pg_attribute SET atttypmod = 20+4 
WHERE attrelid IN ('foo'::regclass, 'voo'::regclass) 
AND attname = 'names'; 

(ध्यान दें:। 20 4 कुछ पागल PostgreSQL विरासत बात, 4 अनिवार्य है):

id  | integer    | not null 
names | character varying(10) | 

बोनस:

अब \d foo शो था ऐसा करने से तेज़ तेज़:

ALTER TABLE foo ALTER COLUMN names TYPE varchar(20); 

तकनीकी रूप से आप तालिका के आकार को बदल सकते हैं दृश्य कॉलम के आकार को बदलने के बिना ओलंपम, लेकिन किन दुष्प्रभावों पर कोई गारंटी नहीं होगी; एक बार में दोनों को बदलने के लिए शायद सबसे अच्छा है।

स्रोत और पूरा विवरण दिया: http://sniptools.com/databases/resize-a-column-in-a-postgresql-table-without-changing-data

+7

आपको जब भी संभव हो मैन्युअल रूप से कैटलॉग (जैसे pg_attribute) को बदलने से बचना चाहिए। कुछ गलत होने और क्रैश और डेटा भ्रष्टाचार समेत त्रुटियों का कारण बनने का वास्तविक खतरा है, बाद में जब आप इसे कम से कम उम्मीद करते हैं। केवल यह सुनिश्चित करने के लिए कि आप कुछ भी याद नहीं कर रहे हैं, स्रोत कोड से परामर्श करने के बाद, अंतिम उपाय के रूप में इसे करें।बिना किसी अस्वीकरण के इसे सुझाव देना गैर जिम्मेदार है। – intgr

+0

इस प्रकार डेटा इंजन वास्तव में दृश्यों के पीछे करता है। आप TYPE नहीं बदल रहे हैं, लेकिन आकार। चूंकि यह वचर है, डेटा के लिए कोई नुकसान नहीं हुआ है। +1 –

2

मैं एक छोटे से पार्टी के लिए देर हो रही है, लेकिन साल के बाद यह सवाल पोस्ट किया गया था, एक प्रतिभाशाली समाधान एक लेख नीचे संदर्भित (मेरा नहीं के माध्यम से पोस्ट किया गया था - मैं कर रहा हूँ बस अपने प्रतिभा का एक आभारी लाभार्थी)।

मैंने इसे 136 अलग-अलग विचारों में संदर्भित (पहले स्तर पर) किसी ऑब्जेक्ट पर परीक्षण किया है, और इनमें से प्रत्येक दृश्य को अन्य विचारों में संदर्भित किया गया है। समाधान केवल सेकंड में भाग गया। PostgreSQL निंजा का जादू के लिए

alter table mdm.global_item_master_swap 
alter column prod_id type varchar(128), 
alter column prod_nme type varchar(512); 

ERROR: cannot alter type of a column used by a view or rule DETAIL: rule _RETURN on view toolbox_reporting."Average_setcost" depends on column "prod_id" ********** Error **********

ERROR: cannot alter type of a column used by a view or rule

और अब:

तो, यह लेख पढ़ सकते हैं और कॉपी और पेस्ट मेज और दो कार्यों सूचीबद्ध:

http://mwenus.blogspot.com/2014/04/postgresql-how-to-handle-table-and-view.html

कार्यान्वयन उदाहरण:

select util.deps_save_and_drop_dependencies('mdm', 'global_item_master_swap'); 


alter table mdm.global_item_master_swap 
alter column prod_id type varchar(128), 
alter column prod_nme type varchar(512); 


select util.deps_restore_dependencies('mdm', 'global_item_master_swap'); 
+0

आप एक महान आत्मा हैं। – Vishnu

संबंधित मुद्दे