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
