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.



On Sat, Mar 4, 2017 at 10:24 AM, Robert Haas <> wrote:

> On Tue, Feb 28, 2017 at 7:34 PM, Tom Lane <> wrote:
> > Surafel Temesgen <> 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
> >> <>
> >
> > 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:
> The Enterprise PostgreSQL Company

Attachment: disallow-multiple-queries-2.patch
Description: Binary data

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to