On 2005-10-26, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andrew - Supernews <andrew+nonews@supernews.com> writes:
>> On 2005-10-26, Tom Lane <tgl@sss.pgh.pa.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