On Tue, 2005-04-26 at 10:28, Tom Lane wrote: > "Greg Sabino Mullane" <[EMAIL PROTECTED]> writes: > > To reiterate my opinion, I think the behavior should be the same > > for interactive and non-interactive sessions. Not only will it > > prevent nasty surprises, but unless we make a third 'setting', > > there will be no way to enable this in non-interactive scripts, > > which is something that I would want to be able to do. > > I'm finding it hard to visualize a non-interactive script making > any good use of such a setting. Without a way to test whether > you got an error or not, it would amount to an "ignore errors > within transactions" mode, which seems a pretty bad idea. > > Can you show a plausible use-case for such a thing? >
I plan to use it in scripts that push site meta-data out to our test servers, where the list of sites are all different so any static data dump is bound to fail on some foreign key checks (but I don't care which ones fail as long as some go over). I'm sure others can come up with different scenarios, but more importantly is I don't see a good reason to treat this setting different from all others and explicitly forbid this use from people, especially when I can imagine people coming from other dbs where this behavior is more common who might in fact expect it to work this way. Robert Treat -- Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match