Re: [HACKERS] [COMMITTERS] Re: pgsql: Code review focused on new node types added by partitioning supp

2017-05-30 Thread Tom Lane 
Robert Haas  writes:
 I'm not really for doing it that way, but I'm willing to apply the fix
 if there's consensus for your position.  Anybody else have an opinion?

> +1 from me, too.  I don't see that there's enough advantage in
> avoiding a catversion bump to justify leaving this footgun behind.

The consensus seems pretty clear.  I'll make it so.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [COMMITTERS] Re: pgsql: Code review focused on new node types added by partitioning supp

2017-05-30 Thread Robert Haas 
On Tue, May 30, 2017 at 5:26 AM, Magnus Hagander  wrote:
>> > I'm not really for doing it that way, but I'm willing to apply the fix
>> > if there's consensus for your position.  Anybody else have an opinion?
>>
>> I tend to agree with Noah on this one.
>
> +1

+1 from me, too.  I don't see that there's enough advantage in
avoiding a catversion bump to justify leaving this footgun behind.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [COMMITTERS] Re: pgsql: Code review focused on new node types added by partitioning supp

2017-05-30 Thread Magnus Hagander 
On Tue, May 30, 2017 at 4:41 AM, Stephen Frost  wrote:

> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Noah Misch  writes:
> > > On Mon, May 29, 2017 at 03:20:41AM +, Tom Lane wrote:
> > >> Annotate the fact that somebody added location fields to
> PartitionBoundSpec
> > >> and PartitionRangeDatum but forgot to handle them in
> > >> outfuncs.c/readfuncs.c.  This is fairly harmless for production
> purposes
> > >> (since readfuncs.c would just substitute -1 anyway) but it's still
> bogus.
> > >> It's not worth forcing a post-beta1 initdb just to fix this, but if we
> > >> have another reason to force initdb before 10.0, we should go back and
> > >> clean this up.
> >
> > > +1 for immediately forcing initdb for this, getting it out of the
> way.  We're
> > > already unlikely to reach 10.0 without bumping catversion, but if we
> otherwise
> > > did, releasing 10.0 with a 10beta1 catversion would have negative
> value.
> >
> > I'm not really for doing it that way, but I'm willing to apply the fix
> > if there's consensus for your position.  Anybody else have an opinion?
>
> I tend to agree with Noah on this one.
>
>
>
+1


-- 
 Magnus Hagander
 Me: https://www.hagander.net/ 
 Work: https://www.redpill-linpro.com/

Re: [HACKERS] [COMMITTERS] Re: pgsql: Code review focused on new node types added by partitioning supp

2017-05-29 Thread Amit Langote 
On 2017/05/30 11:41, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Noah Misch  writes:
>>> On Mon, May 29, 2017 at 03:20:41AM +, Tom Lane wrote:
 Annotate the fact that somebody added location fields to PartitionBoundSpec
 and PartitionRangeDatum but forgot to handle them in
 outfuncs.c/readfuncs.c.  This is fairly harmless for production purposes
 (since readfuncs.c would just substitute -1 anyway) but it's still bogus.
 It's not worth forcing a post-beta1 initdb just to fix this, but if we
 have another reason to force initdb before 10.0, we should go back and
 clean this up.
>>
>>> +1 for immediately forcing initdb for this, getting it out of the way.  
>>> We're
>>> already unlikely to reach 10.0 without bumping catversion, but if we 
>>> otherwise
>>> did, releasing 10.0 with a 10beta1 catversion would have negative value.
>>
>> I'm not really for doing it that way, but I'm willing to apply the fix
>> if there's consensus for your position.  Anybody else have an opinion?
> 
> I tend to agree with Noah on this one.

+1

Thanks,
Amit



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [COMMITTERS] Re: pgsql: Code review focused on new node types added by partitioning supp

2017-05-29 Thread Stephen Frost 
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Noah Misch  writes:
> > On Mon, May 29, 2017 at 03:20:41AM +, Tom Lane wrote:
> >> Annotate the fact that somebody added location fields to PartitionBoundSpec
> >> and PartitionRangeDatum but forgot to handle them in
> >> outfuncs.c/readfuncs.c.  This is fairly harmless for production purposes
> >> (since readfuncs.c would just substitute -1 anyway) but it's still bogus.
> >> It's not worth forcing a post-beta1 initdb just to fix this, but if we
> >> have another reason to force initdb before 10.0, we should go back and
> >> clean this up.
> 
> > +1 for immediately forcing initdb for this, getting it out of the way.  
> > We're
> > already unlikely to reach 10.0 without bumping catversion, but if we 
> > otherwise
> > did, releasing 10.0 with a 10beta1 catversion would have negative value.
> 
> I'm not really for doing it that way, but I'm willing to apply the fix
> if there's consensus for your position.  Anybody else have an opinion?

I tend to agree with Noah on this one.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] [COMMITTERS] Re: pgsql: Code review focused on new node types added by partitioning supp

2017-05-29 Thread Tom Lane 
Noah Misch  writes:
> On Mon, May 29, 2017 at 03:20:41AM +, Tom Lane wrote:
>> Annotate the fact that somebody added location fields to PartitionBoundSpec
>> and PartitionRangeDatum but forgot to handle them in
>> outfuncs.c/readfuncs.c.  This is fairly harmless for production purposes
>> (since readfuncs.c would just substitute -1 anyway) but it's still bogus.
>> It's not worth forcing a post-beta1 initdb just to fix this, but if we
>> have another reason to force initdb before 10.0, we should go back and
>> clean this up.

> +1 for immediately forcing initdb for this, getting it out of the way.  We're
> already unlikely to reach 10.0 without bumping catversion, but if we otherwise
> did, releasing 10.0 with a 10beta1 catversion would have negative value.

I'm not really for doing it that way, but I'm willing to apply the fix
if there's consensus for your position.  Anybody else have an opinion?

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers