+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@xxxxxxxxxxxxx> wrote in message news:28097.1174488581@xxxxxxxxxxxxxxxx > 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/ >
