On Sat, 2002-08-03 at 01:25, Tom Lane wrote: > 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.
When I last time showed how backend_pid function can be trivially defined as hannu=# create function getpid() returns int hannu-# as '/lib/libc.so.6','getpid' language 'C'; CREATE hannu=# select getpid(); getpid -------- 2832 (1 row) You claimed that NOTIFY uses some _other_ backend id (i.e. not process id). But when I now tested it it seems that this is not the case, notify does use the actual process id. hannu=# listen a; LISTEN hannu=# notify a; NOTIFY Asynchronous NOTIFY 'a' from backend with pid 2832 received. > > So I'm still unconvinced that we need or want this ... > And you can do it trivially as long as we support old-style C functions anyway. ------------ Hannu ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
