Re: Patch for psql History Display on MacOSX

From: Noah Misch <noah(at)leadboat(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stepan Rutz <stepan(dot)rutz(at)gmx(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch for psql History Display on MacOSX
Date: 2014-09-03 05:45:04
Message-ID: 20140903054504.GE951259@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 02, 2014 at 09:49:56AM -0400, Tom Lane wrote:
> Noah Misch <noah(at)leadboat(dot)com> writes:
> > I'm with you that far. Given a patch that does not change "\s /tmp/foo" and
> > that makes "\s" equivalent to "\s /tmp/foo" + "\! cat /tmp/foo >/dev/tty",
> > back-patch by all means. No patch posted on this thread is so surgical, hence
> > my objection. In particular, your latest patch revision changes "\s /tmp/foo"
> > to match the novel output the patch introduces for plain "\s". "\s /tmp/foo"
> > would no longer write data that libedit can reload as a history file.
>
> BTW, I failed last night to produce a coherent argument against that
> particular point, but consider this. What are the main use-cases for
> \s to a file? I argue that they are
>
> 1. Create a human-readable record of what you did.
> 2. Create the starting point for a SQL script file.
>
> I do not deny it's possible that somebody out there is also using \s for
>
> 3. Create a file that I can overwrite ~/.psql_history with later.
>
> But if this is being done in the field at all, surely it is miles behind
> the applications listed above.

I'm unprepared to speculate about the relative prevalence of those use cases.

> Now, if you are using libreadline, the output of \s has always been
> perfectly fit for purposes 1 and 2, because it's plain text of the
> history entries. Moreover, it is *not* particularly fit for purpose 3,
> because intra-command newlines aren't encoded. Yes, you could get
> libreadline to read the file, but multiline SQL commands will be seen
> as multiple history entries which is very far from convenient to use.
> (This adds to my suspicion that nobody is doing #3 in practice.)
>
> On the other hand, if you are using libedit, purpose 3 works great
> but the output is utterly unfit for either purpose 1 or 2. Here
> are the first few lines of ~/.psql_history on one of my Macs:
>
> _HiStOrY_V2_
> explain\040verbose\^A\040\040select\0401\^Aunion\^A\040\040select\0402;
> \\q
> select\0404;
> explain\040verbose\^A\040\040select\0401\^Aunion\^A\040\040select\0402;
> select\04044;
> \\q
> \\s
> \\s\040foobar
> \\q
>
> What the proposed patch does is ensure that \s produces plain text
> regardless of which history library you are using. I think arguing
> that we shouldn't do that is stretching the concept of backwards
> compatibility well past the breaking point.

Given the negligible urgency to improve \s, the slightest compatibility hazard
justifies punting this work from back-patch to master-only.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2014-09-03 05:54:09 Re: PL/pgSQL 2
Previous Message Stephen Frost 2014-09-03 05:42:40 Re: ALTER TABLESPACE MOVE command tag tweak