Anyone still using the sql_inheritance parameter?

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