Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Perhaps a more relevant question is why are we cluttering the namespace
> > with any such function at all? What's the use case for it?
> It was requested because it is exposed in libpq and people need it to
> generate unique names and stuff like that from within psql and
> functions. Seems like a valid use for the pid.
The sole reason libpq exposes it is so that you can tell a self-notify
from an incoming notify. (ie, given you are LISTENing on a condition
that both you and other clients send NOTIFYs for, is this particular
message one that you sent yourself, or not? Compare the originator PID
in the NOTIFY message to your backend_pid to find out.) I put that
feature in back around 6.4, because it allowed some important
optimizations in an app I had that used LISTEN/NOTIFY a lot.
Since NOTIFY messages aren't even visible at the SQL level, the above is
not a reason for making PIDs visible at the SQL level.
I'm really dubious about using backend PID for the sort of purpose you
suggest. Unique names would be *much* more safely handled with, say,
a sequence generator. If you are not using libpq or another client
library that can give you a backend-PID API call, then very likely you
don't have a lot of control over the backend connection either, and
shouldn't assume that backend PID is going to be stable for you.
(Think about pooled connections in a webserver, etc.)
Finally, the most legitimate uses of PID (like discovering a backend PID
to send SIGINT to, when some client query is running wild) are not
supported at all by a function that can only return your own backend's
PID, because that's seldom the PID you need to know. The
pg_stat_activity view handles this much better.
So I'm still unconvinced that we need or want this ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
