From: | Stepan Rutz <stepan(dot)rutz(at)gmx(dot)de> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Patch for psql History Display on MacOSX |
Date: | 2014-09-03 20:58:11 |
Message-ID: | 13009106-99FB-4F7C-9A4D-30F3FCF482BE@gmx.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello again, just my thoughts…
in psql \s without a file is nice for me iff going through less (e.g. pager), but for the most part it doesn't work at all on mac-osx. so nothing to lose for the mac psql users.
regards,
stepan
Am 03.09.2014 um 07:45 schrieb Noah Misch <noah(at)leadboat(dot)com>:
> 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.
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-09-03 21:08:12 | Re: postgresql latency & bgwriter not doing its job |
Previous Message | Marti Raudsepp | 2014-09-03 20:55:00 | Re: delta relations in AFTER triggers |