On Mon, Sep 12, 2016 at 11:38 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Mon, Sep 12, 2016 at 10:01 AM, Noah Misch <n...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
