On Tue, Feb 28, 2017 at 7:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Surafel Temesgen <surafel3000@gmail.com> writes:
>> This assignment is on todo list and has a benefit of providing an
>> additional defense against SQL-injection attacks.
>
> This is on the todo list? Really? It seems unlikely to be worth the
> backwards-compatibility breakage. I certainly doubt that we could
> get away with unconditionally rejecting such cases with no "off" switch,
> as you have here.
>
>> Previous mailing list discussion is here
>> <https://www.postgresql.org/message-id/9236.1167968298@sss.pgh.pa.us>
>
> That message points out specifically that we *didn't* plan to do this.
> Perhaps back then (ten years ago) we could have gotten away with the
> compatibility breakage, but now I doubt it.
Probably true, but I bet it would be OK to add this as an optional
behavior, controlled by a GUC. I know behavior-changing GUCs aren't
good, but this seems like a sufficiently-peripheral behavior that it
would be OK. Extensions, for example, wouldn't break, because
they're executing inside the database, not through libpq. Stored
procedures wouldn't break either. The only real risk is that the
user's application itself might break, but there's an easy solution to
that problem.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
