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.
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
