On Mon, Sep 12, 2016 at 11:38 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Mon, Sep 12, 2016 at 10:01 AM, Noah Misch <noah@leadboat.com> wrote:
>> I discourage documenting LF/CR restrictions. For the epsilon of readers who
>> would benefit from this knowledge, the error message suffices. For everyone
>> else, it would just dilute the text. (One could argue against other parts of
>> our documentation on this basis, but I'm not calling for such a study. I'm
>> just saying that today's lack of documentation on this topic is optimal.)
>
> Okay.
>
>>> > > I think the way forward here, if any, is to work on removing these
>>> > > restrictions, not to keep sprinkling them around.
>>> >
>>> > If we were talking about pathnames containing spaces, I would agree,
>>> > but I've never heard of a legitimate pathname containing CR or LF. I
>>> > can't see us losing much by refusing to allow such pathnames, except
>>> > for security holes.
>>
>> (In other words, +1 to that.)
>
> Yep. To be honest, I see value in preventing directly the use of
> newlines and carriage returns in database and role names to avoid
> users to be bitten by custom scripts, things for example written in
> bash that scan manually for pg_database, pg_roles, etc. And I have
> seen such things over the years. Now it is true that the safeguards in
> core are proving to be enough, if only the in-core tools are used, but
> that's not necessarily the case with all the things gravitating around
> this community.
And seeing nothing happening here, I still don't know what to do with
this patch. Thoughts? If we are going to do nothing I would suggest to
just remove the comment in string_utils.c saying that such LF and CR
will be unsupported in a future release and move on.
--
Michael
