On Sat, Jul 18, 2009 at 6:14 AM, Dimitri Fontaine<dfonta...@hi-media.com> wrote: > Le 17 juil. 09 à 23:24, Tom Lane a écrit : >> >> It seems unlikely that the DB version number would be worth the prompt >> space. In situations like that you'd much more likely need identifying >> info like the DB hostname and port number. > > At work we have a fair number of database servers, some 8.2, lots of 8.3, > and still some 8.1 I think. Triple the count for dev and preprod > environments. Of course as the DBA I tend not to forget easily which server > runs which version, and anyway when unsure I read the psql banner. > > But developers too will connect to those servers, and in the same project > they can handle both 8.2 and 8.3 databases. And they already struggle to > think about connecting with the right psql client version. I'm often called > for a "\d is broken, see?". > > All of this to say "from the field" how much I think this could help us to > have a rich prompt with database name and major version. Oh and they could > refer to the right documentation, too, before asking me about why it doesn't > work as intended...
I agree. Probably most people will not use this most of the time, but frequency of use is not necessarily a good criterion for deciding on whether to have a feature. Instead, I think we should look at what the downsides are and if they aren't significant, then we should provide it. In this case, the only apparent downsides are a slight increase in the code maintenance burden (because it adds a slight amount of code) and the fact that it uses up two more %-escapes from a limited set of usable characters. But neither of those arguments impresses me very much. We currently have 11 defined single-character %-escapes and it appears that no new ones have been added since, at the latest, 2003. (I'm too lazy to check the commit that shows up in 'git blame' actually added the line for %x or just modified it.) So there is hardly a run on the namespace, and as for code maintenance we are talking about a very short patch. There is a distributed benefit to PostgreSQL in having a rich feature set. When people look for a feature, they often find that it is already there. That is a sign of a good product. We should continue to aim for that goal. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers