getpid() function
I have implemented this TODO item:
* Add getpid() function to backend
There were a large number of pg_stat functions that access pids and
backends slots so I added it there:
test=> select pg_stat_get_backend_mypid();
pg_stat_get_backend_mypid
---------------------------
2757
(1 row)
Applied.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Attachments:
/bjm/difftext/plainDownload+10-0
On Tue, Jul 30, 2002 at 08:40:13PM -0400, Bruce Momjian wrote:
I have implemented this TODO item:
* Add getpid() function to backend
There were a large number of pg_stat functions that access pids and
backends slots so I added it there:test=> select pg_stat_get_backend_mypid();
If we're going to add it to pg_stat_*, why is 'backend' part of the
name? All the existing backend_* function fetch some piece of data
about a given backend -- whereas this function does not (it takes
no arguments).
IMHO, a better name would be something like 'backend_process_id()',
or 'unix_pid', or 'backend_pid()'.
Also, can you add some documentation on this?
Cheers,
Neil
--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC
OK, renamed to backend_pid() to match the libpq name. I was unsure
about merging it into the stats stuff myself.
setest=> select backend_pid();
backend_pid
-------------
12996
(1 row)
Where does the mention belong in the docs? I have it in the monitoring
section in the stats section right now.
---------------------------------------------------------------------------
Neil Conway wrote:
On Tue, Jul 30, 2002 at 08:40:13PM -0400, Bruce Momjian wrote:
I have implemented this TODO item:
* Add getpid() function to backend
There were a large number of pg_stat functions that access pids and
backends slots so I added it there:test=> select pg_stat_get_backend_mypid();
If we're going to add it to pg_stat_*, why is 'backend' part of the
name? All the existing backend_* function fetch some piece of data
about a given backend -- whereas this function does not (it takes
no arguments).IMHO, a better name would be something like 'backend_process_id()',
or 'unix_pid', or 'backend_pid()'.Also, can you add some documentation on this?
Cheers,
Neil
--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Attachments:
/bjm/difftext/plainDownload+18-10
On Tue, Jul 30, 2002 at 09:48:42PM -0400, Bruce Momjian wrote:
OK, renamed to backend_pid() to match the libpq name.
Ok, thanks.
Where does the mention belong in the docs? I have it in the monitoring
section in the stats section right now.
I'd vote for User's Guide -> Functions & Operators -> Misc. Functions. I
don't think it belongs in the monitoring section, since it isn't part of
the stats collector and isn't really used for monitoring.
Cheers,
Neil
--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC
Neil Conway wrote:
On Tue, Jul 30, 2002 at 09:48:42PM -0400, Bruce Momjian wrote:
OK, renamed to backend_pid() to match the libpq name.
Ok, thanks.
Where does the mention belong in the docs? I have it in the monitoring
section in the stats section right now.I'd vote for User's Guide -> Functions & Operators -> Misc. Functions. I
don't think it belongs in the monitoring section, since it isn't part of
the stats collector and isn't really used for monitoring.
OK, docs moved to new section. I kept the function in pgstatfuncs.c.
Not sure where else to put it.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
nconway@klamath.dyndns.org (Neil Conway) writes:
On Tue, Jul 30, 2002 at 09:48:42PM -0400, Bruce Momjian wrote:
Where does the mention belong in the docs? I have it in the monitoring
section in the stats section right now.
I'd vote for User's Guide -> Functions & Operators -> Misc. Functions.
There is a table in that section for "session information functions",
which seems the correct choice.
regards, tom lane
Tom Lane wrote:
nconway@klamath.dyndns.org (Neil Conway) writes:
On Tue, Jul 30, 2002 at 09:48:42PM -0400, Bruce Momjian wrote:
Where does the mention belong in the docs? I have it in the monitoring
section in the stats section right now.I'd vote for User's Guide -> Functions & Operators -> Misc. Functions.
There is a table in that section for "session information functions",
which seems the correct choice.
That's where I put it.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Tue, Jul 30, 2002 at 09:48:42PM -0400, Bruce Momjian wrote:
OK, renamed to backend_pid() to match the libpq name. I was unsure
about merging it into the stats stuff myself.setest=> select backend_pid();
backend_pid
-------------
12996
(1 row)
Is there some common convention of names? Why not pg_backend_pid()?
Karel
--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote:
Is there some common convention of names?
No, there isn't (for example, pg_stat_backend_id() versus
current_schema() -- or pg_get_viewdef() versus obj_description() ).
Now that we have table functions, we might be using more built-in
functions to provide information to the user -- so there will be
an increasing need for some kind of naming convention for built-in
functions. However, establishing a naming convention without
breaking backwards compatibility might be tricky.
Cheers,
Neil
--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC
On Thu, 2002-08-01 at 10:44, Neil Conway wrote:
On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote:
Is there some common convention of names?
functions. However, establishing a naming convention without
breaking backwards compatibility might be tricky.
Supporting both names for a release with comments in the release notes
stating the old names will disappear soon should be enough.
Most of the time it'll be a simple replacement command. Providing a
find -exec sed statement may help.
On Thu, Aug 01, 2002 at 10:44:23AM -0400, Neil Conway wrote:
On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote:
Is there some common convention of names?
No, there isn't (for example, pg_stat_backend_id() versus
I know -- for this I asked. IMHO for large project like PostgreSQL
it's important. It's not good if there is possible speculate about
name of new function. It must be unmistakable -- for this is needful
make some convension. If somebody add new function and it's released,
it's in the PostgreSQL almost forever.
current_schema() -- or pg_get_viewdef() versus obj_description() ).
Now that we have table functions, we might be using more built-in
functions to provide information to the user -- so there will be
an increasing need for some kind of naming convention for built-in
functions. However, establishing a naming convention without
breaking backwards compatibility might be tricky.
Yes, but we can try be clean for new stuff.
Karel
--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
Added to TODO:
* Consistently name server-side internal functions
---------------------------------------------------------------------------
Karel Zak wrote:
On Thu, Aug 01, 2002 at 10:44:23AM -0400, Neil Conway wrote:
On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote:
Is there some common convention of names?
No, there isn't (for example, pg_stat_backend_id() versus
I know -- for this I asked. IMHO for large project like PostgreSQL
it's important. It's not good if there is possible speculate about
name of new function. It must be unmistakable -- for this is needful
make some convension. If somebody add new function and it's released,
it's in the PostgreSQL almost forever.current_schema() -- or pg_get_viewdef() versus obj_description() ).
Now that we have table functions, we might be using more built-in
functions to provide information to the user -- so there will be
an increasing need for some kind of naming convention for built-in
functions. However, establishing a naming convention without
breaking backwards compatibility might be tricky.Yes, but we can try be clean for new stuff.
Karel
--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026I can rename backend_pid if people want. I just made it consistent
with the other functions in that docs area. Comments?
---------------------------------------------------------------------------
Karel Zak wrote:
On Thu, Aug 01, 2002 at 10:44:23AM -0400, Neil Conway wrote:
On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote:
Is there some common convention of names?
No, there isn't (for example, pg_stat_backend_id() versus
I know -- for this I asked. IMHO for large project like PostgreSQL
it's important. It's not good if there is possible speculate about
name of new function. It must be unmistakable -- for this is needful
make some convension. If somebody add new function and it's released,
it's in the PostgreSQL almost forever.current_schema() -- or pg_get_viewdef() versus obj_description() ).
Now that we have table functions, we might be using more built-in
functions to provide information to the user -- so there will be
an increasing need for some kind of naming convention for built-in
functions. However, establishing a naming convention without
breaking backwards compatibility might be tricky.Yes, but we can try be clean for new stuff.
Karel
--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Thu, 2002-08-01 at 19:41, Bruce Momjian wrote:
Added to TODO:
* Consistently name server-side internal functions
I'd suggest:
* Make up rules for consistently naming server-side internal functions
* Consistently name _new_ server-side internal functions
* make a plan for moving existing server-side internal functions
to consistent naming
---------------
Hannu
On Thu, Aug 01, 2002 at 05:09:52PM +0200, Karel Zak wrote:
I know -- for this I asked. IMHO for large project like PostgreSQL
it's important. It's not good if there is possible speculate about
name of new function. It must be unmistakable -- for this is needful
make some convension. If somebody add new function and it's released,
it's in the PostgreSQL almost forever.
I agree that a naming convention would be useful in some circumstances,
but for commonly-used functions, I think it would do more harm than
good. 'pg_nextval()' is awfully ugly, for example.
And if we're going to have a naming convention for builtin functions,
what about builtin types? 'pg_int4', anyone? :-)
Cheers,
Neil
--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC
Neil Conway writes:
On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote:
Is there some common convention of names?
No, there isn't (for example, pg_stat_backend_id() versus
current_schema() -- or pg_get_viewdef() versus obj_description() ).
The "pg_" naming scheme is obsolete because system and user namespaces are
now isolated. Anything involving "get" is also redundant, IMHO, because
we aren't dealing with object-oriented things. Besides that, the
convention in SQL seems to be to use full noun phrases with words
separated by underscores.
So if "pg_get_viewdef" where reinvented today, by me, it would be called
"view_definition".
A whole 'nother issue is to use the right terms for the right things. For
example, the term "backend" is rather ambiguous and PostgreSQL uses it
differently from everyone else. Instead I would use "server process" when
referring to the PID.
--
Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote:
Neil Conway writes:
On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote:
Is there some common convention of names?
No, there isn't (for example, pg_stat_backend_id() versus
current_schema() -- or pg_get_viewdef() versus obj_description() ).The "pg_" naming scheme is obsolete because system and user namespaces are
now isolated. Anything involving "get" is also redundant, IMHO, because
we aren't dealing with object-oriented things. Besides that, the
convention in SQL seems to be to use full noun phrases with words
separated by underscores.So if "pg_get_viewdef" where reinvented today, by me, it would be called
"view_definition".A whole 'nother issue is to use the right terms for the right things. For
example, the term "backend" is rather ambiguous and PostgreSQL uses it
differently from everyone else. Instead I would use "server process" when
referring to the PID.
Yes, I wanted to match libpq's function, which is the way people used to
get the pid.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
No, there isn't (for example, pg_stat_backend_id() versus
current_schema() -- or pg_get_viewdef() versus obj_description() ).
Now that we have table functions, we might be using more built-in
functions to provide information to the user -- so there will be
an increasing need for some kind of naming convention for built-in
functions. However, establishing a naming convention without
breaking backwards compatibility might be tricky.
I personally think that as many functions as possible should be prefixed
pg_*... People are still used to avoiding pg_ as a prefix.
Chris
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I can rename backend_pid if people want. I just made it consistent
with the other functions in that docs area. Comments?
I'd go for pg_backend_pid, I think. It's not an SQL standard function
and certainly never will be, so some sort of prefix seems appropriate.
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? We've
gotten along fine without one so far, and I don't really think that we
*ought* to be exposing random bits of internal implementation details
at the SQL level.
regards, tom lane
...
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? We've
gotten along fine without one so far, and I don't really think that we
*ought* to be exposing random bits of internal implementation details
at the SQL level.
Actually, I was wondering the same thing, maybe for a different reason.
Exposing the backend internals could have security implications (though
don't make me concoct a scenario to prove it ;)
Although it might have some usefulness for debugging, I think it should
not be an "installed by default" feature, so istm would be a great
candidate for a contrib/ function or library. If someone needs it, it is
almost immediately available.
- Thomas
