Alvaro Herrera writes:
> On 2021-Nov-29, Tom Lane wrote:
>> After some further hackery, here's a set of patches that I think
>> might be acceptable. They're actually fairly independent, although
>> they touch different aspects of the same behavior.
> I tried the collection and I find the overall
On Tue, Nov 30, 2021 at 04:35:13PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, Nov 29, 2021 at 11:12:35PM -0500, Tom Lane wrote:
> >> Interesting. I can probably adjust my MUA to send "text/x-patch",
> >> but I'll have to look around to see where that's determined.
>
> > I would b
Bruce Momjian writes:
> On Mon, Nov 29, 2021 at 11:12:35PM -0500, Tom Lane wrote:
>> Interesting. I can probably adjust my MUA to send "text/x-patch",
>> but I'll have to look around to see where that's determined.
> I would be interesting to know if "text/x-patch" is better than
> "text/x-diff"
On Mon, Nov 29, 2021 at 11:12:35PM -0500, Tom Lane wrote:
> Greg Nancarrow writes:
> > After a bit of investigation, it seems that patch attachments (like
> > yours) with a Context-Type of "text/x-diff" download through Gmail in
> > CRLF format for me (I'm running a browser on Windows, but my Post
Greg Nancarrow writes:
> After a bit of investigation, it seems that patch attachments (like
> yours) with a Context-Type of "text/x-diff" download through Gmail in
> CRLF format for me (I'm running a browser on Windows, but my Postgres
> development environment is in a Linux VM). So those must ge
On Tue, Nov 30, 2021 at 12:15 PM Greg Nancarrow wrote:
>
> Yeah, sorry, looks like it could be a Gmail issue for me.
> When I alternatively downloaded your patches from the pgsql-hackers
> archive, they're in Unix format, as you say.
> After a bit of investigation, it seems that patch attachments
On Tue, Nov 30, 2021 at 11:08 AM Tom Lane wrote:
>
> Greg Nancarrow writes:
> > (BTW, the patches are in Windows CRLF format, so on Linux at least I
> > needed to convert them using dos2unix so they'd apply using Git)
>
> Hmm. Applying "od -c" to the copy of that message that's in my
> PG list f
Greg Nancarrow writes:
> (BTW, the patches are in Windows CRLF format, so on Linux at least I
> needed to convert them using dos2unix so they'd apply using Git)
Hmm. Applying "od -c" to the copy of that message that's in my
PG list folder shows clearly that there's no \r in it, nor do
I see any
On 2021-Nov-29, Tom Lane wrote:
> After some further hackery, here's a set of patches that I think
> might be acceptable. They're actually fairly independent, although
> they touch different aspects of the same behavior.
I tried the collection and I find the overall behavior quite convenient.
I
On Tue, Nov 30, 2021 at 7:56 AM Tom Lane wrote:
>
> After some further hackery, here's a set of patches that I think
> might be acceptable. They're actually fairly independent, although
> they touch different aspects of the same behavior.
>
> 0001 gets rid of psqlscan.l's habit of suppressing das
After some further hackery, here's a set of patches that I think
might be acceptable. They're actually fairly independent, although
they touch different aspects of the same behavior.
0001 gets rid of psqlscan.l's habit of suppressing dash-dash comments,
but only once we have collected some non-wh
Alvaro Herrera writes:
> I wonder if these things would be easier to deal with or more convenient
> if we thought of -- as starting a line-scoped comment, and /* */ as
> starting a query-scoped comment, and treat both types differently. That
> is, a -- comment would not be part of the subsequent
On Mon, 2021-11-29 at 09:43 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > There was one other problem mentioned in the original mail, and that
> > seems to be the most serious one to me:
> > [ HISTCONTROL behavior ]
>
> The actual behavior of that option (which perhaps isn't adequately
> docu
On 2021-Nov-29, Tom Lane wrote:
> Greg's patch would fix this specifically by ensuring that the line
> with the space and comment is treated as a separate history entry.
> So I don't really see that as a separate bug. Or, if you will,
> the fact that people see it as a bug confirms that such a li
Laurenz Albe writes:
> There was one other problem mentioned in the original mail, and that
> seems to be the most serious one to me:
> [ HISTCONTROL behavior ]
The actual behavior of that option (which perhaps isn't adequately
documented) is that it suppresses a history entry if the first
charac
On Sat, 2021-11-27 at 18:30 -0500, Tom Lane wrote:
> Trying to gather together the various issues mentioned on this thread,
> I see:
>
> * Initial input lines that are blank (whitespace, maybe including a
> comment) are merged into the next command's history entry; but since
> said lines don't giv
I wrote:
> We could perhaps finesse that point by deciding that comment lines
> that are handled this way will never be sent to the server --- but
> I'm sure people will complain about that, too. I've definitely heard
> people complain because "--" comments are stripped from what's sent
> (so I'd
On 07.09.21 21:16, Tom Lane wrote:
[ this is a digression from the main point of the thread, but ... ]
Alvaro Herrera writes:
I am particularly bothered by the uselessness
that M-# results in -- namely, inserting a # at the start of the buffer.
Fixing that might be as simple as the attached.
[ this is a digression from the main point of the thread, but ... ]
Alvaro Herrera writes:
> I am particularly bothered by the uselessness
> that M-# results in -- namely, inserting a # at the start of the buffer.
Fixing that might be as simple as the attached. I've not beat on
it hard though.
Alvaro Herrera writes:
> On 2021-Sep-06, Laurenz Albe wrote:
>> I agree with Greg that the current behavior is annoying and would
>> welcome the change. This has bothered me before.
> It has bothered me too.
I'm not here to claim that the current behavior is perfect. However,
AFAICT the patch
On 2021-Sep-06, Laurenz Albe wrote:
> I agree with Greg that the current behavior is annoying and would
> welcome the change. This has bothered me before.
It has bothered me too. I am particularly bothered by the uselessness
that M-# results in -- namely, inserting a # at the start of the buffe
On Mon, Sep 06, 2021 at 07:50:15AM -0700, David G. Johnston wrote:
> On Mon, Sep 6, 2021 at 7:13 AM Greg Nancarrow wrote:
> > I've attached a patch that corrects the behaviour.
> > For the type of lines mentioned, the patch makes the history behave
> > more like Bash history.
The behavior of bash
On Mon, 2021-09-06 at 07:50 -0700, David G. Johnston wrote:
> On Mon, Sep 6, 2021 at 7:13 AM Greg Nancarrow wrote:
> > I've attached a patch that corrects the behaviour.
> > For the type of lines mentioned, the patch makes the history behave
> > more like Bash history.
>
> I have my doubts that y
On Mon, Sep 6, 2021 at 7:13 AM Greg Nancarrow wrote:
> I've attached a patch that corrects the behaviour.
> For the type of lines mentioned, the patch makes the history behave
> more like Bash history.
>
I have my doubts that you've really fixed anything here since Bash is a
line-oriented shell
24 matches
Mail list logo
