Re: sql_inheritance - Mailing list pgsql-bugs

From Tom Lane
Subject Re: sql_inheritance
Date
Msg-id 14262.1534513761@sss.pgh.pa.us
Whole thread Raw
In response to sql_inheritance  (Piotr Stegmann <p.stegmann@adith.com.pl>)
List pgsql-bugs
Piotr Stegmann <p.stegmann@adith.com.pl> writes:
> in PostgreSQL 10 version was removed param: sql_inheritance. Robert Haas
> was explained why was this happend. Hovewer, we are using PostgreSQL since
> 2004 and using some other developers replication system for which this
> param was important. This is one thing. Other thing is that our software
> was unable to make upgrade because one of sql upgrade script use
> sql_inheritance. So we cant do that. At this moment we are unable to do
> upgrade our software because of not compatible with older version. We cant
> offer new PostgreSQL version because of error in our upgrade system.

> Is it possible to bring it back?

No, I don't think we're going to do that.  The behavior with
sql_inheritance = off has been deprecated since 2000; that seems like
more than enough time to have adjusted any software depending on it.

Furthermore, keeping the variable is not without cost, because really
any software that depends on the normal behavior ought to be capable
of dealing with the case where it's been turned off.  In practice
nobody does that, meaning that there's surely a lot of latent bugs
caused by its existence.

If we had kept it, we'd also have had to figure out its interaction
with the new partitioning features, which is a mess nobody wanted to
deal with.  So that's probably why it went away when it did and not
at some other time ... but really, it had little excuse to live.

            regards, tom lane


pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bug: ERROR: invalid cache ID: 42 CONTEXT: parallel worker
Next
From: Andrew Gierth
Date:
Subject: Re: BUG #15336: Wrong cursor's bacward fetch results in select with ALL(subquery)