Re: Forbid use of LF and CR characters in database and role names

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(dot)paquier(at)gmail(dot)com> wrote:
> > On Mon, Sep 12, 2016 at 10:01 AM, Noah Misch <noah(at)leadboat(dot)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