Is anybody still using the ability to set sql_inheritance to OFF? I'm considering removing the parameter in PG 8.3, so that the current default behavior (sql_inheritance = ON) would be the only behavior. sql_inheritance was created in 7.1 to allow existing applications to not be broken when we changed the default behavior, but I have not heard of anyone using it recently. The argument for removing it is basically that user-settable parameters that affect fundamental query semantics are dangerous. As an example, setting sql_inheritance to OFF causes silent malfunctioning of partitioned tables that are built using the currently-recommended approach. You could even argue that this is a security hole, because an unprivileged user could cause a security-definer function to fail to operate as intended --- okay, that's a bit of a stretch, but the scenario is not out of the question. We've recently been discussing the possibility that the search_path parameter could be used to force misbehavior of security-definer functions. There seems to be consensus in favor of adding language features to let creators of functions nail down the search_path to be used by their functions (though there's not a specific proposal yet). I don't really want to go through similar pushups for sql_inheritance; it doesn't seem worth it. So: would anyone cry if sql_inheritance disappeared in 8.3? If there are a lot of complaints, a possible compromise is to keep the variable but make it SUSET, ie, only changeable by superusers. This would still allow the setting to be turned off for use by legacy applications (probably by means of ALTER USER) while removing the objection that non-privileged users could break things. regards, tom lane
