Tom Lane wrote: > Unfortunately, if the default behavior doesn't change, then there's little > argument for doing this at all. The security reasoning behind doing > anything in this area would be to provide an extra measure of protection > against SQL-injection attacks on carelessly-written clients, and of course > it's unlikely that a carelessly-written client would get changed to make > use of a non-default feature.
A patch introducing an "allow_multiple_queries" GUC to control this was proposed and eventually rejected for lack of consensus some time ago (also there were some concerns about the implementation that might have played against it too): https://www.postgresql.org/message-id/CALAY4q_eHUx%3D3p1QUOvabibwBvxEWGm-bzORrHA-itB7MBtd5Q%40mail.gmail.com About the effectiveness of this feature, there's a valid use case in which it's not the developers who decide to set this GUC, but the DBA or the organization deploying the application. That applies to applications that of course do not intentionally use multiple queries per command. That would provide a certain level a protection against SQL injections, without changing the application or libpq or breaking backward compatibility, being optional. But both in this thread and the other thread, the reasoning about the GUC seems to make the premise that applications would need to be updated or developpers need to be aware of it, as if they _had_ to issue SET allow_multiple_queries TO off/on, rather than being submitted to it, as imposed upon them by postgresql.conf or the database settings. If we compare this to, say, lo_compat_privileges. An application typically doesn't get to decide whether it's "on". It's for a superuser to decide which databases or which users must operate with this setting to "on". Why wouldn't that model work for disallowing multiple queries per command? Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite
