Andres Freund wrote: > Since it's an application writer's choice whether to use it, > it seems to make not that much sense to have a > serverside guc - it can't really be sensible set.
The application writers who are concerned by this wouldn't know that they have a choice. If there were informed, supposedly they would grok the SQL syntax to begin with, understanding the necessity and workings of proper quoting, and the problem would not exist. What is proposed AFAIU is an optional policy to be set on already developed client apps, not a setting that is meant to be played with by them. An analogy I can find in existing GUCs, and that incidentally is actually relevant to me as an app writer, is lo_compat_privileges It's SUSET, it's not GUC_REPORT. Either it's on and the app is not subject to permission checking for large objects, or it's off and it is subject to them. It's something that is relevant at deployment time, and not really besides that, and it's the DBA's problem to set the policy depending on the app requirements and the security requirements, rather than the app's problem to adjust to whatever value there is in there. As an example of app requirement, if the app has to let a user create a large object and a different user to delete it, this GUC must be on, otherwise such a scenario is not allowed, as unlinking is not a grantable privilege, just like drop table. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers