Robert Haas writes:
> On Fri, Dec 23, 2016 at 11:59 AM, Tom Lane wrote:
>> Do you have any particular objection to taking the next step of removing
>> enum InhOption in favor of making inhOpt a bool?
> No, not really. I don't feel like it's an
On Fri, Dec 23, 2016 at 11:59 AM, Tom Lane wrote:
> Robert Haas writes:
>> Great, committed. I realize just now that I forgot to credit anyone
>> as a reviewer, but hopefully nobody's going to mind that too much
>> considering this is a purely
Robert Haas writes:
> Great, committed. I realize just now that I forgot to credit anyone
> as a reviewer, but hopefully nobody's going to mind that too much
> considering this is a purely mechanical patch I wrote in 20 minutes.
Do you have any particular objection to
On Mon, Dec 19, 2016 at 12:25 AM, Amit Langote
wrote:
>> I agree. Patch attached, just removing the GUC and a fairly minimal
>> amount of the supporting infrastructure.
>
> +1 to removing the sql_inheritance GUC. The patch looks good to me.
Great, committed. I
On Mon, Dec 19, 2016 at 11:48 AM, Alvaro Herrera
wrote:
> Any particular reason not to change inhOpt to be a simple boolean, and
> remove the enum?
No, no particular reason. I thought about it, but I didn't really see
any advantage in getting rid of the typedef.
--
Robert Haas wrote:
> On Fri, Dec 16, 2016 at 7:39 PM, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> On 12/16/16 11:05 AM, Robert Haas wrote:
> >>> If we were going to do anything about this,
> >>> my vote would be to remove
On 2016/12/17 10:40, Robert Haas wrote:
> On Fri, Dec 16, 2016 at 7:39 PM, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> On 12/16/16 11:05 AM, Robert Haas wrote:
If we were going to do anything about this,
my vote would be to
On Fri, Dec 16, 2016 at 7:39 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 12/16/16 11:05 AM, Robert Haas wrote:
>>> If we were going to do anything about this,
>>> my vote would be to remove sql_inheritance.
>
>> Go for it.
>
>> Let's
Peter Eisentraut writes:
> On 12/16/16 11:05 AM, Robert Haas wrote:
>> If we were going to do anything about this,
>> my vote would be to remove sql_inheritance.
> Go for it.
> Let's also remove the table* syntax then.
Meh --- that might break existing
On 12/16/16 11:05 AM, Robert Haas wrote:
> If we were going to do anything about this,
> my vote would be to remove sql_inheritance.
+1. This option is long past the intended shelf life.
--
-David
da...@pgmasters.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On 12/16/16 11:05 AM, Robert Haas wrote:
> If we were going to do anything about this,
> my vote would be to remove sql_inheritance.
Go for it.
Let's also remove the table* syntax then.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote
On Fri, Dec 16, 2016 at 2:34 PM, David Fetter wrote:
> It occurs to me this probably isn't the only GUC that's basically just
> a foot gun at this point.
>
> Is 10 a good time to sweep and clear them?
We never make any progress trying to do these things "in bulk". If
you think
On Fri, Dec 16, 2016 at 11:05:21AM -0500, Robert Haas wrote:
> On Thu, Dec 15, 2016 at 10:40 AM, Dmitry Ivanov
> wrote:
> > Hi everyone,
> >
> > Looks like "sql_inheritance" GUC is affecting partitioned tables:
> >
> > [breaks literally everything]
> >
> > I might be
Robert Haas writes:
> An earlier version of Amit's patches tried to handle this by forcing
> sql_inheritance on for partitioned tables, but it wasn't
> well-implemented and I don't see the point anyway. Sure, turning off
> sql_inheritance off for partitioned tables
On Thu, Dec 15, 2016 at 10:40 AM, Dmitry Ivanov wrote:
> Hi everyone,
>
> Looks like "sql_inheritance" GUC is affecting partitioned tables:
>
> explain (costs off) select * from test;
> QUERY PLAN --
> Append
> -> Seq Scan
15 matches
Mail list logo