Sorry for being very late. I also think guc version of the patch can be acceptable and useful.
I modified the patch as such and added to commitfest 2017-07. Regards Surafel On Sat, Mar 4, 2017 at 10:24 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Feb 28, 2017 at 7:34 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Surafel Temesgen <surafel3...@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.1167968...@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 >
disallow-multiple-queries-2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
