Re: Disallowing multiple queries per PQexec()

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 <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, Feb 28, 2017 at 7:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Surafel Temesgen <surafel3000(at)gmail(dot)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
>