On Tue, Nov 22, 2016 at 11:06 PM, Pavel Stehule
wrote:
>
>
> 2016-11-22 13:02 GMT+01:00 Oleksandr Shulgin >:
>
>> On Tue, Nov 22, 2016 at 5:28 AM, Pavel Stehule
>> wrote:
>>
>>>
>>> 2016-11-22 3:46 GMT+01:00 Robert Haas :
>>>
On Mon, Nov 21, 2016 at 4:55 AM, Oleksandr Shulgin
wrote:
2016-11-22 13:02 GMT+01:00 Oleksandr Shulgin :
> On Tue, Nov 22, 2016 at 5:28 AM, Pavel Stehule
> wrote:
>
>>
>> 2016-11-22 3:46 GMT+01:00 Robert Haas :
>>
>>> On Mon, Nov 21, 2016 at 4:55 AM, Oleksandr Shulgin
>>> wrote:
>>> > On Tue, Nov 15, 2016 at 4:10 PM, Jim Nasby
>>> wrote:
>>> >>
>>> >>
On Tue, Nov 22, 2016 at 5:28 AM, Pavel Stehule
wrote:
>
> 2016-11-22 3:46 GMT+01:00 Robert Haas :
>
>> On Mon, Nov 21, 2016 at 4:55 AM, Oleksandr Shulgin
>> wrote:
>> > On Tue, Nov 15, 2016 at 4:10 PM, Jim Nasby
>> wrote:
>> >>
>> >> On 11/14/16 5:41 AM, Oleksandr Shulgin wrote:
>> >>>
>> >>> A
2016-11-22 3:46 GMT+01:00 Robert Haas :
> On Mon, Nov 21, 2016 at 4:55 AM, Oleksandr Shulgin
> wrote:
> > On Tue, Nov 15, 2016 at 4:10 PM, Jim Nasby
> wrote:
> >>
> >> On 11/14/16 5:41 AM, Oleksandr Shulgin wrote:
> >>>
> >>> Automatic connection reset is a nice feature for server development,
>
On Mon, Nov 21, 2016 at 4:55 AM, Oleksandr Shulgin
wrote:
> On Tue, Nov 15, 2016 at 4:10 PM, Jim Nasby wrote:
>>
>> On 11/14/16 5:41 AM, Oleksandr Shulgin wrote:
>>>
>>> Automatic connection reset is a nice feature for server development,
>>> IMO. Is it really useful for anything else is a good
On Tue, Nov 15, 2016 at 4:10 PM, Jim Nasby wrote:
> On 11/14/16 5:41 AM, Oleksandr Shulgin wrote:
>
>> Automatic connection reset is a nice feature for server development,
>> IMO. Is it really useful for anything else is a good question.
>>
>
> I use it all the time for application development;
On 11/14/16 5:41 AM, Oleksandr Shulgin wrote:
Automatic connection reset is a nice feature for server development,
IMO. Is it really useful for anything else is a good question.
I use it all the time for application development; my rebuild script
will forcibly kick everyone out to re-create t
On Fri, Nov 11, 2016 at 5:37 AM, Pavel Stehule
wrote:
>
> 2016-11-11 5:14 GMT+01:00 Ashutosh Bapat
> :
>
>> >
>> > How about, instead of all this, adding an option to psql to suppress
>> > the automatic reconnect behavior? When enabled, psql just exits
>> > instead of trying to reconnect.
>> >
2016-11-11 5:14 GMT+01:00 Ashutosh Bapat :
> >
> > How about, instead of all this, adding an option to psql to suppress
> > the automatic reconnect behavior? When enabled, psql just exits
> > instead of trying to reconnect.
> >
> +1. But, existing users may not notice addition of the new option a
>
> How about, instead of all this, adding an option to psql to suppress
> the automatic reconnect behavior? When enabled, psql just exits
> instead of trying to reconnect.
>
+1. But, existing users may not notice addition of the new option and
still continue to face problem. If we add the option
On Tue, Nov 8, 2016 at 9:53 AM, Oleksandr Shulgin
wrote:
> On Mon, Nov 7, 2016 at 9:31 PM, Jim Nasby wrote:
>>
>> On 11/4/16 4:04 AM, Oleksandr Shulgin wrote:
>>>
>>> The psql process even exits with an error code 2, which might be not
>>> that expected. We could stop reading the file and reset
On Mon, Nov 7, 2016 at 9:31 PM, Jim Nasby wrote:
> On 11/4/16 4:04 AM, Oleksandr Shulgin wrote:
>
>> The psql process even exits with an error code 2, which might be not
>> that expected. We could stop reading the file and reset connection
>> afterwards, but this is probably not that easy to ach
On 11/4/16 4:04 AM, Oleksandr Shulgin wrote:
The psql process even exits with an error code 2, which might be not
that expected. We could stop reading the file and reset connection
afterwards, but this is probably not that easy to achieve (think of
nested \i calls).
Well, if you stop reading f
On Thu, Nov 3, 2016 at 12:26 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
>
> A couple of doubts/suggestions:
> 1. Should pset.conn_was_reset be set to false, when we make a
> connection in do_connection()? Usually pset.conn_was_reset would be
> initialised with 0 since it's a glob
On Thu, Oct 20, 2016 at 3:58 PM, Oleksandr Shulgin
wrote:
> Hi Hackers!
>
> When using psql interactively one might be tempted to guard potentially
> destructive commands such as "UPDATE / DELETE / DROP " by starting
> the input line with an explicit "BEGIN; ...". This has the added benefit
> tha
On Thu, Oct 20, 2016 at 5:25 PM, Oleksandr Shulgin
wrote:
> On Thu, Oct 20, 2016 at 12:28 PM, Oleksandr Shulgin
> wrote:
>>
>>
>> Since this is already an improvement, I'm attaching a patch.
>>
>> If on the other hand, someone is pasting into psql's terminal a block of
>> commands enclosed in BEG
On Thu, Oct 20, 2016 at 12:28 PM, Oleksandr Shulgin <
oleksandr.shul...@zalando.de> wrote:
>
> Since this is already an improvement, I'm attaching a patch.
>
> If on the other hand, someone is pasting into psql's terminal a block of
> commands enclosed in BEGIN/COMMIT, the same bug is triggered: B
On Thu, Oct 20, 2016 at 12:28 PM, Oleksandr Shulgin <
oleksandr.shul...@zalando.de> wrote:
>
>
> I'm not the first one to discover that, a search in archives gives at
least 3 results:
>
>
https://www.postgresql.org/message-id/flat/1097174870.9273.8.camel%40ipso.snappymail.ca#1097174870.9273.8.ca...
Hi Hackers!
When using psql interactively one might be tempted to guard potentially
destructive commands such as "UPDATE / DELETE / DROP " by starting
the input line with an explicit "BEGIN; ...". This has the added benefit
that then you invoke the command by reverse-searching the command history
19 matches
Mail list logo
