On Sat, 2002-08-03 at 01:25, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> 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
