RE: Timeout parameters

From: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
To: 'Fabien COELHO' <coelho(at)cri(dot)ensmp(dot)fr>
Cc: "Nagaura, Ryohei" <nagaura(dot)ryohei(at)jp(dot)fujitsu(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "Jamison, Kirk" <k(dot)jamison(at)jp(dot)fujitsu(dot)com>, "Michael Paquier" <michael(at)paquier(dot)xyz>, "AYahorau(at)ibagroup(dot)eu" <AYahorau(at)ibagroup(dot)eu>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "MikalaiKeida(at)ibagroup(dot)eu" <MikalaiKeida(at)ibagroup(dot)eu>
Subject: RE: Timeout parameters
Date: 2019-03-14 09:05:04
Message-ID: 0A3221C70F24FB45833433255569204D1FBC75A4@G01JPEXMBYT05
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

From: Fabien COELHO [mailto:coelho(at)cri(dot)ensmp(dot)fr]
> I think that the typical use-case of \c is to connect to another database
> on the same host, at least that what I do pretty often. The natural
> expectation is that the same "other" connection parameters are used,
> otherwise it does not make much sense, and there is already a whole logic
> of reusing the previous settings in psql, at least wrt describing the
> target (host, port, user…).

I agree about the natural expectation.

> > Anyway, I think this would be an improvement for psql's documentation
> or
> > new feature for psql. What do you think?
>
> I think that we should fix the behavior rather than document the current
> weirdness. I do not think that we should introduce more weirdness.

Do you think all connection parameter settings should be reused by default, or when -reuse-previous=on is specified?

Do you think this is a bug to be backported to previous versions, or a new feature? I think I'll make a patch separately from this thread, if time permits.

Regards
Takayuki Tsunakawa

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2019-03-14 09:07:13 Re: jsonpath
Previous Message David Rowley 2019-03-14 09:04:11 Re: speeding up planning with partitions