Re: procpid? - Mailing list pgsql-hackers

From Cédric Villemain
Subject Re: procpid?
Date
Msg-id BANLkTin8eD2N01QQjdxr+gmUJCvLTp6Q9Q@mail.gmail.com
Whole thread Raw
In response to Re: procpid?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: procpid?
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [v9.1] sepgsql - userspace access vector cache
Next
From: Robert Haas
Date:
Subject: Re: hot standby startup, visibility map, clog