Re: add_missing_from breaks existing views

On 2005-10-26, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew - Supernews <andrew+nonews(at)supernews(dot)com> writes:
>> On 2005-10-26, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Uh, no ... the global setting of add_missing_from does *not* tell you
>>> anything about whether there exist views in the database that were
>>> created under a different setting.
>
>> I realize that; but is it also not the case that someone who creates a
>> view that requires add_missing_from, and then turns it off, has _already_
>> broken dump+restore on his own database?
>
> No, because we consider that a client-local setting. This argument is
> akin to saying that if a client loads some data with client_encoding FOO
> into a database with server_encoding BAR, we are not responsible for
> dumping and reloading the data correctly.

8.0:

test=# show add_missing_from;
add_missing_from
------------------
off
(1 row)

test=# set add_missing_from to true;
SET
test=# create view v1 as select test.*;
CREATE VIEW
test=# \q

% pg_dump -U pgsql -s -d test | psql -U pgsql -d test2

[...]
ERROR: missing FROM-clause entry for table "test"
ERROR: relation "public.v1" does not exist

Looks broken to me.

I wasn't arguing that the broken behaviour was correct, merely that it
exists.

> In hindsight I think there's no doubt that we blew it in not making
> ruleutils.c reverse-list implicit RTEs some time ago.

Obviously. Isn't hindsight wonderful.

> Pretending it's the user's mistake isn't
> an answer that fits down my craw very well...

I'm not claiming it's the user's mistake. My point is that if the user
did in fact remove add_missing_from after creating views that depend on it,
then they have already run into a bug.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services