On Sat, 2021-04-03 at 17:43 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > Attached is version 6.
>
> Pushed with some mostly-cosmetic fiddling.
>
> One thing I changed that wasn't cosmetic is that as you had it,
> the behavior of "\e file" varied depending on whether the query
> buffer had b
Laurenz Albe writes:
> Attached is version 6.
Pushed with some mostly-cosmetic fiddling.
One thing I changed that wasn't cosmetic is that as you had it,
the behavior of "\e file" varied depending on whether the query
buffer had been empty, which surely seems like a bad idea.
I made it do discard
On Fri, 2021-03-12 at 13:12 -0500, Tom Lane wrote:
> I pushed the race-condition-fixing part of this, since that's an
> unarguable bug fix and hence seems OK to back-patch. (I added a
> check on change of file size, because why not.)
Thank you!
> Attached is the rest, just to keep the cfbot happ
Laurenz Albe writes:
> Done like that in the attached patch version 4.
I pushed the race-condition-fixing part of this, since that's an
unarguable bug fix and hence seems OK to back-patch. (I added a
check on change of file size, because why not.)
Attached is the rest, just to keep the cfbot ha
On Wed, 2021-03-10 at 00:13 -0500, Tom Lane wrote:
> I agree
> that trying to get rid of the race condition inherent in the existing
> file mtime test would be a good idea. However, I've got some
> portability-related gripes about how you are doing the latter:
>
> 1. There is no principled reason
On Wed, Mar 10, 2021 at 6:14 AM Tom Lane wrote:
>
> PS: I seem to recall that some Microsoft filesystems have 2-second
> resolution on file mod times, so maybe it needs to be "time(NULL) - 2"?
>
You are thinking about FAT:
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-ge
Laurenz Albe writes:
> On Thu, 2021-03-04 at 16:51 +, Jacob Champion wrote:
>> You could backdate the temporary file, so that any save is guaranteed
>> to move the timestamp forward. That should work even if the filesystem
>> has extremely poor precision.
> Ah, of course, that is the way to g
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
Very nice quality-of-life improvement. Thanks!
The new status of
On Thu, 2021-03-04 at 16:51 +, Jacob Champion wrote:
> > I am not against fixing or improving the behavior, but given the
> > fact that we can't portably get less than second precision, it
> > seems impossible.
>
> You could backdate the temporary file, so that any save is guaranteed
> to move
On Thu, 2021-03-04 at 17:41 +0100, Laurenz Albe wrote:
> So if you do your "modify and save the file in less than a second"
> trick with the old code, you would end up with the old, unmodified
> data in the query buffer.
Sorry, I was unclear in my first post -- I'm not modifying the
temporary file
On Wed, 2021-03-03 at 17:12 +, Jacob Champion wrote:
> On Wed, 2021-03-03 at 17:08 +0100, Laurenz Albe wrote:
> > This is no new behavior, and I think this is rare enough that we don't
> > have to bother.
>
> I agree that it's not new behavior, but this patch exposes that
> behavior for the te
On Wed, 2021-03-03 at 17:08 +0100, Laurenz Albe wrote:
> This is no new behavior, and I think this is rare enough that we don't
> have to bother.
I agree that it's not new behavior, but this patch exposes that
behavior for the temporary file case, because you've fixed the bug that
caused the times
Thanks for testing!
On Wed, 2021-03-03 at 00:07 +, Jacob Champion wrote:
> On Wed, 2020-12-16 at 10:45 +0100, Laurenz Albe wrote:
>
> > I consider this a bug fix, but one that shouldn't be backpatched.
> > Re-executing the previous query if the editor is quit is
> > annoying at least and dang
On Wed, 2020-12-16 at 10:45 +0100, Laurenz Albe wrote:
> I consider this a bug fix, but one that shouldn't be backpatched.
> Re-executing the previous query if the editor is quit is
> annoying at least and dangerous at worst.
I like that this patch also clears the query buffer in the error case.
(
On Tue, 2020-12-01 at 11:34 -0500, Chapman Flack wrote:
> On 12/01/20 11:21, Laurenz Albe wrote:
> > On Tue, 2020-12-01 at 11:03 -0500, Chapman Flack wrote:
> > > > I propose to clear the query buffer if the
> > > > editor exits without modifying the file.
> > >
> > > Or how about keeping the quer
On 12/01/20 11:21, Laurenz Albe wrote:
> On Tue, 2020-12-01 at 11:03 -0500, Chapman Flack wrote:
>>> complain about it, so I propose to clear the query buffer if the
>>> editor exits without modifying the file.
>>
>> Or how about keeping the query buffer content unchanged, but not
>> executing it?
On Tue, 2020-12-01 at 11:03 -0500, Chapman Flack wrote:
> On 11/30/20 22:38, Laurenz Albe wrote:
> > I have been annoyed about this myself, and I have heard other prople
> > complain about it, so I propose to clear the query buffer if the
> > editor exits without modifying the file.
>
> Or how abo
On 11/30/20 22:38, Laurenz Albe wrote:
> I have been annoyed about this myself, and I have heard other prople
> complain about it, so I propose to clear the query buffer if the
> editor exits without modifying the file.
Or how about keeping the query buffer content unchanged, but not
executing it
If you quit the editor without saving, the current query buffer
or the last executed SQL statement get run.
This can be annoying and disruptive, and it requires you to
empty the file and save it if you don't want to execute anything.
But when editing a script, it is a clear POLA violation:
test=
19 matches
Mail list logo
