Re: psql doesn't reuse -p after backend fail - Mailing list pgsql-bugs

From Robert Haas
Subject Re: psql doesn't reuse -p after backend fail
Date
Msg-id CA+TgmoZ10jzgLsEaN=80Na9_orTG=8F2u23gaqw9xjYmRq736w@mail.gmail.com
Whole thread Raw
In response to Re: psql doesn't reuse -p after backend fail  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: psql doesn't reuse -p after backend fail  (Bruce Momjian <bruce@momjian.us>)
List pgsql-bugs
On Thu, Sep 8, 2011 at 5:09 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On tis, 2011-09-06 at 17:12 +0200, hubert depesz lubaczewski wrote:
>> On Mon, Sep 05, 2011 at 02:27:23PM -0400, Tom Lane wrote:
>> > It's not just the port, it's all the connection parameters ---
>> > do_connect relies on the PGconn object to remember those, and in this
>> > case there no longer is a PGconn object.
>> >
>> > We could have psql keep that information separately, but I'm not sure
>> > it's really worth the trouble.
>>
>> well, I think it's definitely worth the trouble. If I had datbaase
>> standing at 5432, it would connect to it, and then I could mistakenly
>> ran commands to wrong database.
>> this is clearly not a good thing.
>
> Perhaps just prevent \connect without argument if the information is no
> longer available.

I think it'd be worth actually having psql maintain the information
separately from the PGconn... but if nobody feels motivated to go do
that, doing at least this much would remove the foot-gun.  So +1 for
that.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgsql-bugs by date:

Previous
From: Robert Haas
Date:
Subject: Re: Dropped index on table preventing rule creation
Next
From: "Eduardo Piombino"
Date:
Subject: BUG #6207: fali to get lock on parent table after two consecutive updates to the same row in child table