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.
--
Michael