Re: procpid? - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: procpid?
Date
Msg-id BANLkTimCJamtVe1nHMwZGNrv6UCgtPDKPQ@mail.gmail.com
Whole thread Raw
In response to Re: procpid?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: procpid?
Re: procpid?
Re: procpid?
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: FOREIGN TABLE doc fix
Next
From: Aidan Van Dyk
Date:
Subject: Re: FOREIGN TABLE doc fix