From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Tightening up allowed custom GUC names |
Date: | 2021-02-11 19:50:13 |
Message-ID: | CA+TgmoaR_dW4ZxhMW8+eUijnqVEyxZikhdfBSP5G=5jczdSFPQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 9, 2021 at 6:02 PM Noah Misch <noah(at)leadboat(dot)com> wrote:
> > * A case could be made for tightening things up a lot more, and not
> > allowing anything that doesn't look like an identifier. I'm not
> > pushing for that, as it seems more likely to break existing
> > applications than the narrow restriction proposed here. But I could
> > live with it if people prefer that way.
>
> I'd prefer that. Characters like backslash, space, and double quote have
> significant potential to reveal bugs, while having negligible application
> beyond revealing bugs.
I'm not sure exactly what the rule should be here, but in general I
agree that a broader prohibition might be better. It's hard to
understand the rationale behind a system that doesn't allow
robert.max-workers as a GUC name, but does permit ro
b"ert.max^Hworkers.
+1 for not back-patching whatever we do here.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2021-02-11 20:04:17 | Re: Tightening up allowed custom GUC names |
Previous Message | Robert Haas | 2021-02-11 19:40:08 | Re: repeated decoding of prepared transactions |