From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | "Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Noah Misch <noah(at)leadboat(dot)com> |
Subject: | Re: Forbid use of LF and CR characters in database and role names |
Date: | 2017-02-01 04:31:25 |
Message-ID: | CAB7nPqTDyQkPYgHhuzgn-YDBeijK2Q1_ksT+hfxh94MfTp7MBg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 29, 2016 at 1:33 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Fri, Nov 25, 2016 at 4:41 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> On Fri, Nov 25, 2016 at 4:02 PM, Ideriha, Takeshi
>> <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com> wrote:
>>> I applied your fixed patch and new one, and confirmed the applied source passed the tests successfully. And I also checked manually the error messages were emitted successfully when cr/lf are included in dbname or rolename or data_directory.
>>>
>>> AFAICT, this patch satisfies the concept discussed before. So I’ve switched this patch “Ready for Committer”.
>>
>> Thanks for the review, Ideriha-san. (See you next week perhaps?)
>
> Patch moved to CF 2017-01.
And nothing has happened since, the patch rotting a bit because of a
conflict in pg_dump's TAP tests. Attached is a rebased version.
--
Michael
Attachment | Content-Type | Size |
---|---|---|
0001-Forbid-newline-and-carriage-return-characters-in-dat.patch | application/octet-stream | 8.3 KB |
0002-Ensure-clean-up-of-data-directory-even-with-restrict.patch | application/octet-stream | 4.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-02-01 04:31:46 | Re: Forbid use of LF and CR characters in database and role names |
Previous Message | Michael Paquier | 2017-02-01 04:21:40 | Re: Measuring replay lag |