On 2005-10-26, Tom Lane <[EMAIL PROTECTED]> wrote: > Andrew - Supernews <[EMAIL PROTECTED]> writes: >> On 2005-10-26, Tom Lane <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
