Re: apple uses Postgres for RemoteDesktop 2
От | Tom Lane |
---|---|
Тема | Re: apple uses Postgres for RemoteDesktop 2 |
Дата | |
Msg-id | 19262.1092813737@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: apple uses Postgres for RemoteDesktop 2 (Joel <rees@ddcom.co.jp>) |
Ответы |
Re: apple uses Postgres for RemoteDesktop 2
|
Список | pgsql-general |
Joel <rees@ddcom.co.jp> writes: > "Scott Marlowe" <smarlowe@qwest.net> wrote >> Why can't the user and the OS use the same server? > Apple does some "weird" stuff with things. We learned this lesson from Cobalt, actually. Even if the OS installs an absolutely vanilla version of Postgres, it's a bad idea. The first problem is that the user may want to use a different PG version than the OS does. ("Maybe not today, and maybe not tomorrow, but soon ... and for the rest of your life ...") The second problem is that the user is going to want superuser privs over his database, including the ability to rm -rf it, initdb it, and possibly crash it if he's doing development; this is not something you want happening to part of the core GUI. (Cobalt had this problem in spades because their PG database *was* part of the core GUI. Screw around with it, and you'd be lucky if you could log in again. I trust that Remote Desktop isn't that core to OS X, but I'd still not care to admin that database while logged in through Remote Desktop.) Even if you think that Joe Average User won't want to do this stuff, a Postgres developer who owns an Apple machine (moi for instance) certainly will. Is it in Apple's interest to make life hard for the developers of a technology they are depending on? > I suppose that the best advice to give the OP on this is to point out > how he can set up his own install of postgresql to use another port. This is backwards. The OS should stay out of the user's way, not vice versa. If the OS wants its own private PG server, I am surely all for that ... but it should not commandeer the port the user would expect to use for *his* PG server. regards, tom lane
В списке pgsql-general по дате отправления: