Re: WIP patch for TODO Item: Add prompt escape to display the client and server versions

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Dickson S(dot) Guedes" <listas(at)guedesoft(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: WIP patch for TODO Item: Add prompt escape to display the client and server versions
Date: 2009-07-19 11:42:34
Message-ID: 603c8f070907190442m1aa61828ra55fcbceb627caa8@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jul 18, 2009 at 6:14 AM, Dimitri Fontaine<dfontaine(at)hi-media(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2009-07-19 12:39:33 Re: generic explain options v3 - RR Review
Previous Message Robert Haas 2009-07-19 11:28:35 Re: Review: Revise parallel pg_restore's scheduling heuristic