Re: Anyone still using the sql_inheritance parameter?

+1;

Tom:

I regularly use the inheritance features of postgreSQL -- Probably 25% of my
schemas rely on it for the techiques I use such as: history tables,
recursion tables [parent-child and trees], among others.

What is the potential impact for the "ONLY" qualifier ??? None I would
expect, as the "ONLY" qualifier effectively sets SQL_INHERITANCE = off for
that specific query --

What about "decorated" table names: i.e: "SELECT * FROM cities*" ??? Do we
get to keep this feature ? [my understanding: table_name* is the reverse
alternative to "ONLY" in that it queries all tables in the inheritance tree]

My vote would be to have the global setting become settable in the runtime
environment only by a superuser, or as specified in the global settings
[postgresql.conf] --> assuming that the ONLY qualifier and decorated table
names continue to work as they currently do...

The manual encourages the use of "ONLY" -- [see sql_inheritance -- section
17.12.1].

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in message
news:28097(dot)1174488581(at)sss(dot)pgh(dot)pa(dot)us(dot)(dot)(dot)
> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org/
>