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
Hi,
Single lines entered in PSQL interactive-mode, containing just
whitespace or an SQL comment ("--..."), don't seem to be stored
correctly in the history.
For example, such lines are currently prepended to the history of the
next command entered, rather than having their own history entry.
Also,
25 matches
Mail list logo
