Re: Forbid use of LF and CR characters in database and role names - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Forbid use of LF and CR characters in database and role names
Date
Msg-id 20161011020015.GA1031972@tornado.leadboat.com
Whole thread Raw
In response to Re: Forbid use of LF and CR characters in database and role names  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Forbid use of LF and CR characters in database and role names  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
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.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?

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



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Macro customizable hashtable / bitmapscan & aggregation perf
Next
From: Andres Freund
Date:
Subject: Re: Macro customizable hashtable / bitmapscan & aggregation perf