add_missing_from breaks existing views

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: add_missing_from breaks existing views
Date: 2005-10-25 21:43:27
Message-ID: 29284.1130276607@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-10-25 21:55:21 Re: expanded \df+ display broken in beta4
Previous Message Michael Paesold 2005-10-25 21:33:14 Re: expanded \df+ display broken in beta4