Thread: 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
> So: would anyone cry if sql_inheritance disappeared in 8.3?
+1
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/21/07 09:49, Tom Lane wrote: > 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. > [snip] > > 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. Shouldn't features be deprecated for a version before removal? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGAVKxS9HxQb37XmcRAmTbAKDfcRX1zP5NWqVjiiAb/p5KL8vdPACePdip HCIWBGMMbZVkUuO92h+fOos= =sVjt -----END PGP SIGNATURE-----
+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@sss.pgh.pa.us> wrote in message news:28097.1174488581@sss.pgh.pa.us... > 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/ >
Ron Johnson <ron.l.johnson@cox.net> writes:
> On 03/21/07 09:49, Tom Lane wrote:
>> Is anybody still using the ability to set sql_inheritance to OFF?
> Shouldn't features be deprecated for a version before removal?
Effectively, that feature's been deprecated since 7.1 ...
regards, tom lane
"codeWarrior" <gpatnude@hotmail.com> writes:
> 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 ?
Sure, I see no need to muck with either of those syntaxes.
regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/21/07 11:13, Tom Lane wrote: > Ron Johnson <ron.l.johnson@cox.net> writes: >> On 03/21/07 09:49, Tom Lane wrote: >>> Is anybody still using the ability to set sql_inheritance to OFF? > >> Shouldn't features be deprecated for a version before removal? > > Effectively, that feature's been deprecated since 7.1 ... But not explicitly. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGAWJHS9HxQb37XmcRAtciAKC6IYE3EsdcMe4Y6mKKu143URsXzgCffjOY EqkoNv0cOMfQShN2WZcQ0Ro= =CPNn -----END PGP SIGNATURE-----