add_missing_from breaks existing views
От | Tom Lane |
---|---|
Тема | add_missing_from breaks existing views |
Дата | |
Msg-id | 29284.1130276607@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: add_missing_from breaks existing views
Re: add_missing_from breaks existing views Re: add_missing_from breaks existing views |
Список | pgsql-hackers |
Sample case: regression=# create table t1(f1 int, f2 int); CREATE TABLE regression=# set add_missing_from = true; SET regression=# create view v1 as select t1.*; NOTICE: adding missing FROM-clause entry for table "t1" CREATE VIEW regression=# \d v1 View "public.v1"Column | Type | Modifiers --------+---------+-----------f1 | integer |f2 | integer | View definition:SELECT t1.f1, t1.f2; The problem with this is that pg_dump will dump the view exactly like that: $ pg_dump -t v1 regression ... -- -- Name: v1; Type: VIEW; Schema: public; Owner: postgres -- CREATE VIEW v1 AS SELECT t1.f1, t1.f2; ALTER TABLE public.v1 OWNER TO postgres; and therefore the dump will fail to load into a machine with add_missing_from set to false. What I suggest we do about this is change addImplicitRTE() to set inFromCl true for implicitly added RTEs, so that the view rule will later be dumped as if the query had been written per spec. The problem with this is that it does not retroactively fix existing dumps (and pg_dump can't force the backend to list the view correctly, so "use 8.1 pg_dump" is no answer). That leaves us with two not very appealing choices: 1. Tell people they may have to set add_missing_from = true to reload a dump that contains such views. 2. Revert the change to make add_missing_from default as false, and wait a few more releases before making it default. Comments? regards, tom lane
В списке pgsql-hackers по дате отправления: