2015-05-22 20:28 GMT+02:00 Jim Nasby <jim.na...@bluetreble.com>: > On 5/21/15 7:12 AM, Robert Haas wrote: > >> On Wed, May 20, 2015 at 8:46 PM, Andres Freund <and...@anarazel.de> >> wrote: >> >>> I've a hard time believing it's actually a good idea to change this. It >>> pretty much seems to only be useful if you're doing unqualified SELECT >>> pg_cancel_backend(pid) FROM pg_stat_activity; type queries. I don't see >>> that as something we need to address. >>> >> >> +1. I'm not saying this isn't annoying - I've been annoyed by it >> myself - but IMHO it's really not worth having two functions that do >> 99% the same thing. Then, instead of having to remember to exclude >> your own backend using the same SQL syntax you use for everything >> else, you have to remember which of two similarly-named functions to >> call if you don't want to kill your own backend. That might be better >> for some people, but it won't be better for everyone. >> > > OTOH, if we allowed RAISE FATAL in plpgsql there'd be no need for > self-termination via pg_terminate_backend(). I also don't see a problem > with allowing self-termination, with the default being to disallow it. > > I suspect the number of people writing code that need self-termination is > very, very small, whereas probably every DBA out there has been bitten by > this. This is the type of thing that gives Postgres a reputation for being > 'hard to use'. I would think the benefit of the larger group would outweigh > the pain the smaller group would feel changing their code, but of course > that's just my opinion and I don't see any easy way to quantify that. > > You and Andreas think it's fine as-is. > Tom and Jon Nelson maybe don't like it as-is, but won't break backwards > compatibility. >
I am with Tom and Jon - I don't see a good enough reason why to change long used behave without more users reports. Possibility to kill self is simple test, so this feature is working. Regards Pavel > David Steele and I seem fine with breaking compat., not sure about > Fabrizio. > > Given the opposition unless some others speak up I'll just drop it. > -- > Jim Nasby, Data Architect, Blue Treble Consulting > Data in Trouble? Get it in Treble! http://BlueTreble.com > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
