|From:||Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>|
|To:||Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>|
|Cc:||Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: [HACKERS] pgbench - allow to store select results into variables|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
>>>>> "Andrew" == Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
>>> This patch contains CRLF line endings
>> Alas, not according to "file" nor "hexdump" (only 0A, no 0D) on my
>> local version, AFAICS.
>> What happens on the path and what is done by mail clients depending
>> on the mime type is another question (eg text/x-diff or text/plain).
Andrew> It's not done by my MUA, and it's present in your latest posted
Andrew> patch. If anything I'd suspect your MUA:
The patch in the original email is in text/plain with base64 transfer
encoding, which means that CRLF line endings are mandatory. It's
actually up to the receiving MUA (or the archives webserver) to undo
If the archives webserver isn't handling that then it's a bug there.
|Next Message||Fabien COELHO||2018-08-14 11:38:21||Re: [HACKERS] pgbench - allow to store select results into variables|
|Previous Message||Andrew Dunstan||2018-08-14 11:11:03||Re: Uncaught PHP Exception Doctrine\DBAL\Exception\UniqueConstraintViolationException: "An exception occurred while executing 'UPDATE|