procpid?

Bruce Momjian <bruce@momjian.us> writes:

Can someone explain why pg_stat_activity has a column named procpid and
not simply pid? 'pid' is that pg_locks uses, and 'procpid' is redundant
(proc-process-id). A mistake?

Mistake or not, it's about half a dozen releases too late to change it.

regards, tom lane

On Thu, Jun 9, 2011 at 11:54 AM, Bruce Momjian <bruce@momjian.us> wrote:

Can someone explain why pg_stat_activity has a column named procpid and
not simply pid?  'pid' is that pg_locks uses, and 'procpid' is redundant
(proc-process-id).  A mistake?

Well, we refer to the slots that backends use as "procs" (really
PGPROC), so I'm guessing that this was intended to mean "the pid
associated with the proc". It might not be the greatest name but I
can't see changing it now.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas wrote:

On Thu, Jun 9, 2011 at 11:54 AM, Bruce Momjian <bruce@momjian.us> wrote:

Can someone explain why pg_stat_activity has a column named procpid and
not simply pid? ?'pid' is that pg_locks uses, and 'procpid' is redundant
(proc-process-id). ?A mistake?

Well, we refer to the slots that backends use as "procs" (really
PGPROC), so I'm guessing that this was intended to mean "the pid
associated with the proc". It might not be the greatest name but I
can't see changing it now.

Agreed. Just pointing out this mistake slipped through.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On Jun 9, 2011, at 11:29 AM, Robert Haas wrote:

On Thu, Jun 9, 2011 at 11:54 AM, Bruce Momjian <bruce@momjian.us> wrote:

Can someone explain why pg_stat_activity has a column named procpid and
not simply pid? 'pid' is that pg_locks uses, and 'procpid' is redundant
(proc-process-id). A mistake?

Well, we refer to the slots that backends use as "procs" (really
PGPROC), so I'm guessing that this was intended to mean "the pid
associated with the proc". It might not be the greatest name but I
can't see changing it now.

It's damn annoying... enough so that I'd personally be in favor of creating a pid column that has the same data so we can deprecate procpid and eventually remove it...
--
Jim C. Nasby, Database Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net

On Sat, Jun 11, 2011 at 12:02 AM, Jim Nasby <jim@nasby.net> wrote:

It's damn annoying... enough so that I'd personally be in favor of creating a pid column that has the same data so we can deprecate
procpid and eventually remove it...

well, if we will start changing bad picked names we will have a *lot*
of work to do... starting by the project's name ;)

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación

On 6/11/2011 1:02 AM, Jaime Casanova wrote:

On Sat, Jun 11, 2011 at 12:02 AM, Jim Nasby<jim@nasby.net> wrote:

It's damn annoying... enough so that I'd personally be in favor of creating a pid column that has the same data so we can deprecate
procpid and eventually remove it...

well, if we will start changing bad picked names we will have a *lot*
of work to do... starting by the project's name ;)

There is a difference between a project name and something that directly
affects usability. +1 on fixing this. IMO, we don't create a new pid
column, we just fix the problem. If we do it for 9.2, we have 18 months
to communicate the change.

Joshua D. Drake

Joshua D. Drake wrote:

On 6/11/2011 1:02 AM, Jaime Casanova wrote:

On Sat, Jun 11, 2011 at 12:02 AM, Jim Nasby<jim@nasby.net> wrote:

It's damn annoying... enough so that I'd personally be in favor of creating a pid column that has the same data so we can deprecate
procpid and eventually remove it...

well, if we will start changing bad picked names we will have a *lot*
of work to do... starting by the project's name ;)

There is a difference between a project name and something that directly
affects usability. +1 on fixing this. IMO, we don't create a new pid
column, we just fix the problem. If we do it for 9.2, we have 18 months
to communicate the change.

Uh, I am the first one I remember complaining about this so I don't see
why we should break compatibility for such a low-level problem.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On 6/11/2011 1:23 PM, Bruce Momjian wrote:

There is a difference between a project name and something that directly
affects usability. +1 on fixing this. IMO, we don't create a new pid
column, we just fix the problem. If we do it for 9.2, we have 18 months
to communicate the change.

Uh, I am the first one I remember complaining about this so I don't see
why we should break compatibility for such a low-level problem.

Because it is a very real problem with an easy fix. We have 18 months to
publicize that fix. I mean really? This is a no-brainer.

JD

On Sat, Jun 11, 2011 at 9:15 PM, Joshua D. Drake <jd@commandprompt.com> wrote:

On 6/11/2011 1:23 PM, Bruce Momjian wrote:

There is a difference between a project name and something that directly
affects usability. +1 on fixing this. IMO, we don't create a new pid
column, we just fix the problem. If we do it for 9.2, we have 18 months
to communicate the change.

Uh, I am the first one I remember complaining about this so I don't see
why we should break compatibility for such a low-level problem.

Because it is a very real problem with an easy fix. We have 18 months to
publicize that fix. I mean really? This is a no-brainer.

I really don't see what the big deal with calling it the process PID
rather than just the PID is. Changing something like this forces
pgAdmin and every other application out there that is built to work
with PG to make a code change to keep working with PG. That seems
like pushing a lot of unnecessary work on other people for what is
basically a minor cosmetic issue.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

2011/6/12 Robert Haas <robertmhaas@gmail.com>:

On Sat, Jun 11, 2011 at 9:15 PM, Joshua D. Drake <jd@commandprompt.com> wrote:

On 6/11/2011 1:23 PM, Bruce Momjian wrote:

There is a difference between a project name and something that directly
affects usability. +1 on fixing this. IMO, we don't create a new pid
column, we just fix the problem. If we do it for 9.2, we have 18 months
to communicate the change.

Uh, I am the first one I remember complaining about this so I don't see
why we should break compatibility for such a low-level problem.

Because it is a very real problem with an easy fix. We have 18 months to
publicize that fix. I mean really? This is a no-brainer.

I really don't see what the big deal with calling it the process PID
rather than just the PID is.  Changing something like this forces
pgAdmin and every other application out there that is built to work
with PG to make a code change to keep working with PG.  That seems
like pushing a lot of unnecessary work on other people for what is
basically a minor cosmetic issue.

I agree.
This is at least a use-case for something^Wfeature like 'create
synonym', allowing smooth end-user's application upgrade on schema
update. I am not claiming that we need that, it just seems a good
usecase for column alias/synonym.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support

On Sat, Jun 11, 2011 at 9:56 PM, Cédric Villemain
<cedric.villemain.debian@gmail.com> wrote:

2011/6/12 Robert Haas <robertmhaas@gmail.com>:

On Sat, Jun 11, 2011 at 9:15 PM, Joshua D. Drake <jd@commandprompt.com> wrote:

On 6/11/2011 1:23 PM, Bruce Momjian wrote:

There is a difference between a project name and something that directly
affects usability. +1 on fixing this. IMO, we don't create a new pid
column, we just fix the problem. If we do it for 9.2, we have 18 months
to communicate the change.

Uh, I am the first one I remember complaining about this so I don't see
why we should break compatibility for such a low-level problem.

Because it is a very real problem with an easy fix. We have 18 months to
publicize that fix. I mean really? This is a no-brainer.

I really don't see what the big deal with calling it the process PID
rather than just the PID is.  Changing something like this forces
pgAdmin and every other application out there that is built to work
with PG to make a code change to keep working with PG.  That seems
like pushing a lot of unnecessary work on other people for what is
basically a minor cosmetic issue.

I agree.
This is at least a use-case for something^Wfeature like 'create
synonym', allowing smooth end-user's application upgrade on schema
update. I am not claiming that we need that, it just seems a good
usecase for column alias/synonym.

I had the same thought. I'm not sure that this particular example
would be worthwhile even if we had a column synonym facility. But at
least if we were bent on changing it we could do it without breaking
things.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On lör, 2011-06-11 at 16:23 -0400, Bruce Momjian wrote:

Uh, I am the first one I remember complaining about this so I don't
see why we should break compatibility for such a low-level problem.

I complain about it every day to the wall. :)

Peter Eisentraut <peter_e@gmx.net> writes:

On lör, 2011-06-11 at 16:23 -0400, Bruce Momjian wrote:

Uh, I am the first one I remember complaining about this so I don't
see why we should break compatibility for such a low-level problem.

I complain about it every day to the wall. :)

+1 !
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

On Jun 11, 2011, at 9:36 PM, Robert Haas wrote:

This is at least a use-case for something^Wfeature like 'create
synonym', allowing smooth end-user's application upgrade on schema
update. I am not claiming that we need that, it just seems a good
usecase for column alias/synonym.

I had the same thought. I'm not sure that this particular example
would be worthwhile even if we had a column synonym facility. But at
least if we were bent on changing it we could do it without breaking
things.

A synonym feature would definitely be useful for cases like this. We have a poorly named database at work; it's been that way for years and the only reason it's never been cleaned up is because it would require simultaneously changing config settings in dozens of places on hundreds of machines (many of which are user machines, which makes performing the change very difficult). As annoying as dealing with the oddball name is (there's a number of pieces of code that have to special case it), it would be even more painful to fix the problem. If we had database name synonyms we could create a synonym and migrate everything over time... and in the meantime, code could stop special-casing it.
--
Jim C. Nasby, Database Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net

On Mon, Jun 13, 2011 at 11:20 AM, Jim Nasby <jim@nasby.net> wrote:

On Jun 11, 2011, at 9:36 PM, Robert Haas wrote:

This is at least a use-case for something^Wfeature like 'create
synonym', allowing smooth end-user's application upgrade on schema
update. I am not claiming that we need that, it just seems a good
usecase for column alias/synonym.

I had the same thought.  I'm not sure that this particular example
would be worthwhile even if we had a column synonym facility.  But at
least if we were bent on changing it we could do it without breaking
things.

A synonym feature would definitely be useful for cases like this. We have a poorly named database at work; it's been that way for years and the only reason it's never been cleaned up is because it would require simultaneously changing config settings in dozens of places on hundreds of machines (many of which are user machines, which makes performing the change very difficult). As annoying as dealing with the oddball name is (there's a number of pieces of code that have to special case it), it would be even more painful to fix the problem. If we had database name synonyms we could create a synonym and migrate everything over time... and in the meantime, code could stop special-casing it.

That's probably the best explanation of why synonyms would be useful I
believe I've yet heard.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Jun 13, 2011, at 10:22 AM, Robert Haas wrote:

A synonym feature would definitely be useful for cases like this. We have a poorly named database at work; it's been that way for years and the only reason it's never been cleaned up is because it would require simultaneously changing config settings in dozens of places on hundreds of machines (many of which are user machines, which makes performing the change very difficult). As annoying as dealing with the oddball name is (there's a number of pieces of code that have to special case it), it would be even more painful to fix the problem. If we had database name synonyms we could create a synonym and migrate everything over time... and in the meantime, code could stop special-casing it.

That's probably the best explanation of why synonyms would be useful I
believe I've yet heard.

FWIW, I've asked Command Prompt to look into creating database name synonyms for us, but perhaps there are other synonyms that would make sense? I can't really think of any other cases where you care about name and don't have a way to work around it (ie: column and tables can be done with views; you can grant a role to another role; you can create a wrapper function).
--
Jim C. Nasby, Database Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net

On Sun, Jun 12, 2011 at 2:23 AM, Robert Haas <robertmhaas@gmail.com> wrote:

On Sat, Jun 11, 2011 at 9:15 PM, Joshua D. Drake <jd@commandprompt.com> wrote:

On 6/11/2011 1:23 PM, Bruce Momjian wrote:

There is a difference between a project name and something that directly
affects usability. +1 on fixing this. IMO, we don't create a new pid
column, we just fix the problem. If we do it for 9.2, we have 18 months
to communicate the change.

Uh, I am the first one I remember complaining about this so I don't see
why we should break compatibility for such a low-level problem.

Because it is a very real problem with an easy fix. We have 18 months to
publicize that fix. I mean really? This is a no-brainer.

I really don't see what the big deal with calling it the process PID
rather than just the PID is.  Changing something like this forces
pgAdmin and every other application out there that is built to work
with PG to make a code change to keep working with PG.  That seems
like pushing a lot of unnecessary work on other people for what is
basically a minor cosmetic issue.

+1

If we were going to make changes like this, I'd suggest we save them
up in a big bag for when we change major version number. Everybody in
the world thinks that PostgreSQL v8 is compatible across all versions
(8.0, 8.1, 8.2, 8.3, 8.4), and it will be same with v9. That way we
would still have forward progress, but in more sensible sized steps.
Otherwise we just break the code annually for all the people that
support us. If we had a more stable environment for tools vendors,
maybe people wouldn't need to be manually typing procpid anyway...

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

On Mon, Jun 13, 2011 at 11:56 AM, Simon Riggs <simon@2ndquadrant.com> wrote:

+1

If we were going to make changes like this, I'd suggest we save them
up in a big bag for when we change major version number. Everybody in
the world thinks that PostgreSQL v8 is compatible across all versions
(8.0, 8.1, 8.2, 8.3, 8.4), and it will be same with v9. That way we
would still have forward progress, but in more sensible sized steps.
Otherwise we just break the code annually for all the people that
support us. If we had a more stable environment for tools vendors,
maybe people wouldn't need to be manually typing procpid anyway...

Amen.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Simon Riggs wrote:

On Sun, Jun 12, 2011 at 2:23 AM, Robert Haas <robertmhaas@gmail.com> wrote:

On Sat, Jun 11, 2011 at 9:15 PM, Joshua D. Drake <jd@commandprompt.com> wrote:

On 6/11/2011 1:23 PM, Bruce Momjian wrote:

There is a difference between a project name and something that directly
affects usability. +1 on fixing this. IMO, we don't create a new pid
column, we just fix the problem. If we do it for 9.2, we have 18 months
to communicate the change.

Uh, I am the first one I remember complaining about this so I don't see
why we should break compatibility for such a low-level problem.

Because it is a very real problem with an easy fix. We have 18 months to
publicize that fix. I mean really? This is a no-brainer.

I really don't see what the big deal with calling it the process PID
rather than just the PID is. ?Changing something like this forces
pgAdmin and every other application out there that is built to work
with PG to make a code change to keep working with PG. ?That seems
like pushing a lot of unnecessary work on other people for what is
basically a minor cosmetic issue.

+1

If we were going to make changes like this, I'd suggest we save them
up in a big bag for when we change major version number. Everybody in
the world thinks that PostgreSQL v8 is compatible across all versions
(8.0, 8.1, 8.2, 8.3, 8.4), and it will be same with v9. That way we
would still have forward progress, but in more sensible sized steps.
Otherwise we just break the code annually for all the people that
support us. If we had a more stable environment for tools vendors,
maybe people wouldn't need to be manually typing procpid anyway...

Agreed. I did add a C comment that this was misnamed so when we are in
that code we will see it. I did reorder the pg_stat_activity columns in
9.0 for sanity, and no one complained, but renaming is more disruptive
than reordering.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +