On Sun, Oct 02, 2016 at 10:47:04PM +0900, Michael Paquier wrote: > 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?
I count one person disfavoring the patch concept of rejecting these characters early, and I count two people, plus yourself as author, favoring it. Therefore, the patch can move forward with the proposed design. The next step, then, is for the patch to park in a CommitFest until someone volunteers to review the implementation details. nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers