Re: procpid?
От | Robert Haas |
---|---|
Тема | Re: procpid? |
Дата | |
Msg-id | BANLkTin39Sm6STezAWXCMi5i7At9di+0eQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: procpid? (Cédric Villemain <cedric.villemain.debian@gmail.com>) |
Ответы |
Re: procpid?
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: