Bruce Momjian <[EMAIL PROTECTED]> writes:
> Sorry, I mean pg_backend_pid.
Okay, I was unsure if that was a typo or not.
> I could expose backend_id but it may
> confuse people so pid is probably better. If you had the id, you could
> use pg_stat_get_backend_pid() to get the pid.
Yeah, I though
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Let's take it out and wait to see if anyone really still wants it.
>
> > Just when I am ready to throw it away, I come up with a use for the
> > function:
>
> > test=> select * from pg_stat_activity where procpid != backend_pid
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Let's take it out and wait to see if anyone really still wants it.
> Just when I am ready to throw it away, I come up with a use for the
> function:
> test=> select * from pg_stat_activity where procpid != backend_pid();
> This shows all activi
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > As I remember, most cases where people have recently been asking for
> > backend pid were related to temp tables because they were named by pid.
>
> Ah, good point.
>
> > I don't think they are anymore. (?)
>
> Check.
>
> > We c
Bruce Momjian <[EMAIL PROTECTED]> writes:
> As I remember, most cases where people have recently been asking for
> backend pid were related to temp tables because they were named by pid.
Ah, good point.
> I don't think they are anymore. (?)
Check.
> We can do two things. We can either renam
As I remember, most cases where people have recently been asking for
backend pid were related to temp tables because they were named by pid.
I don't think they are anymore. (?)
We can do two things. We can either rename it to pg_backend_pid and
move it to the statistics section in the docs, w
Hannu Krosing <[EMAIL PROTECTED]> writes:
> You claimed that NOTIFY uses some _other_ backend id (i.e. not process
> id).
I did? Must have been momentary brain fade on my part. It's always
been process ID.
regards, tom lane
---(end of broadcast)
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
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
Thomas Lockhart wrote:
> ...
> > 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 inter
On Fri, Aug 02, 2002 at 05:38:37PM +0900, Tatsuo Ishii wrote:
> > 2/ PostgreSQL specific functions used in standard SQL operations
> >
> > (the function works with standard data and not load it from
> > internal PostgreSQL stuff).
> >
> > For example convert(), all datetype functi
> > For example convert(), all datetype function like int(). The name
> > convenition must be like names in group 1/
>
> FYI, I have been proposing SQL99 compatible convert(). I would like to
> add it if no one objects.
No objection, but what does it do out of interest? Will it cause a
b
> 2/ PostgreSQL specific functions used in standard SQL operations
>
> (the function works with standard data and not load it from
> internal PostgreSQL stuff).
>
> For example convert(), all datetype function like int(). The name
> convenition must be like names in group 1/
On Thu, Aug 01, 2002 at 01:41:49PM -0400, Bruce Momjian wrote:
>
> Added to TODO:
>
> * Consistently name server-side internal functions
OK, good start of discussion is define groups of the PostgreSQL
functions:
1/ Extern compatible functions
The functions compatible with stand
...
> 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 t
Bruce Momjian <[EMAIL PROTECTED]> 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 seem
> 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 kin
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() ).
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
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
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 f
I 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
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:
>
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 PostgreS
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
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
f
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
>
Tom Lane wrote:
> [EMAIL PROTECTED] (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 & Oper
[EMAIL PROTECTED] (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.
T
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
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 & Operator
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
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_ge
33 matches
Mail list logo
