Thread: Is this a bug?

On Wed, Mar 12, 2014 at 11:11 PM, Fabrízio de Royes Mello
<fabriziomello@gmail.com> wrote:
> Hi all,
>
> Shouldn't the "ALTER" statements below raise an exception?
>
> fabrizio=# CREATE TABLE foo(bar SERIAL PRIMARY KEY);
> CREATE TABLE
>
> fabrizio=# SELECT relname, reloptions FROM pg_class WHERE relname ~ '^foo';
>    relname   | reloptions
> -------------+------------
>  foo         |
>  foo_bar_seq |
>  foo_pkey    |
> (3 rows)
>
> fabrizio=# ALTER TABLE foo RESET (noname);
> ALTER TABLE
>
> fabrizio=# ALTER INDEX foo_pkey RESET (noname);
> ALTER INDEX
>
> fabrizio=# ALTER TABLE foo ALTER COLUMN bar RESET (noname);
> ALTER TABLE
>
>
> If I try to "SET" an option called "noname" obviously will raise an
> exception:
>
> fabrizio=# ALTER TABLE foo SET (noname=1);
> ERROR:  unrecognized parameter "noname"

Well, it's fairly harmless, but it might not be a bad idea to tighten that up.

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

On 13-03-2014 00:11, Fabrízio de Royes Mello wrote:
> Shouldn't the "ALTER" statements below raise an exception?
> 
For consistency, yes. Who cares? I mean, there is no harm in resetting
an unrecognized parameter. Have in mind that tighten it up could break
scripts. In general, I'm in favor of validating things.

euler@euler=# reset noname;
ERROR:  42704: unrecognized configuration parameter "noname"
LOCAL:  set_config_option, guc.c:5220


--   Euler Taveira                   Timbira - http://www.timbira.com.br/  PostgreSQL: Consultoria, Desenvolvimento,
Suporte24x7 e Treinamento
 

<div dir="ltr"><div class="gmail_extra"><br />On Thu, Mar 13, 2014 at 10:34 AM, Euler Taveira <<a
href="mailto:euler@timbira.com.br">euler@timbira.com.br</a>>wrote:<br />><br />> On 13-03-2014 00:11, Fabrízio
deRoyes Mello wrote:<br /> > > Shouldn't the "ALTER" statements below raise an exception?<br />> ><br
/>>For consistency, yes. Who cares? I mean, there is no harm in resetting<br />> an unrecognized parameter. Have
inmind that tighten it up could break<br /> > scripts. In general, I'm in favor of validating things.<br />><br
/></div><divclass="gmail_extra"><br />I know this could break scripts, but I think a consistent behavior should be
raisean exception when an option doesn't exists.<br /><br />> euler@euler=# reset noname;<br />> ERROR:  42704:
unrecognizedconfiguration parameter "noname"<br />> LOCAL:  set_config_option, guc.c:5220<br />><br /><br
/></div><divclass="gmail_extra">This is a consistent behavior.<br /><br /></div><div class="gmail_extra">Regards,<br
/></div><divclass="gmail_extra"><br />--<br />Fabrízio de Royes Mello<br />Consultoria/Coaching PostgreSQL<br
/>>>Timbira: <a href="http://www.timbira.com.br">http://www.timbira.com.br</a><br /> >> Blog sobre TI: <a
href="http://fabriziomello.blogspot.com">http://fabriziomello.blogspot.com</a><br/>>> Perfil Linkedin: <a
href="http://br.linkedin.com/in/fabriziomello">http://br.linkedin.com/in/fabriziomello</a><br/> >> Twitter: <a
href="http://twitter.com/fabriziomello">http://twitter.com/fabriziomello</a></div></div>

fabriziomello wrote
> On Thu, Mar 13, 2014 at 10:34 AM, Euler Taveira <

> euler@.com

> >
> wrote:
>>
>> On 13-03-2014 00:11, Fabrízio de Royes Mello wrote:
>> > Shouldn't the "ALTER" statements below raise an exception?
>> >
>> For consistency, yes. Who cares? I mean, there is no harm in resetting
>> an unrecognized parameter. Have in mind that tighten it up could break
>> scripts. In general, I'm in favor of validating things.
>>
>
> I know this could break scripts, but I think a consistent behavior should
> be raise an exception when an option doesn't exists.
>
>> euler@euler=# reset noname;
>> ERROR:  42704: unrecognized configuration parameter "noname"
>> LOCAL:  set_config_option, guc.c:5220
>>
>
> This is a consistent behavior.
>
> Regards,

Probably shouldn't back-patch but a fix and release comment in 9.4 is
warranted.

Scripts resetting invalid parameters are probably already broken, they just
haven't discovered their mistake yet.

Do we need an "IF EXISTS" feature on these as well? ;)

David J.







--
View this message in context: http://postgresql.1045698.n5.nabble.com/Is-this-a-bug-tp5795831p5795943.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.

On Tue, Mar 18, 2014 at 10:24 AM, Fabrízio de Royes Mello
<fabriziomello@gmail.com> wrote:
>
> On Thu, Mar 13, 2014 at 10:22 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Well, it's fairly harmless, but it might not be a bad idea to tighten that
>> up.
> The attached patch tighten that up.
Hm... It might be interesting to include it in 9.4 IMO, somewhat
grouping with what has been done in a6542a4 for SET and ABORT.
--
Michael

On Mon, Mar 17, 2014 at 10:27 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Tue, Mar 18, 2014 at 10:24 AM, Fabrízio de Royes Mello
> <fabriziomello@gmail.com> wrote:
>>
>> On Thu, Mar 13, 2014 at 10:22 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> Well, it's fairly harmless, but it might not be a bad idea to tighten that
>>> up.
>> The attached patch tighten that up.
> Hm... It might be interesting to include it in 9.4 IMO, somewhat
> grouping with what has been done in a6542a4 for SET and ABORT.

Meh.  There will always be another thing we could squeeze in; I don't
think this is particularly urgent, and it's late to the party.

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

On Tue, Mar 18, 2014 at 09:11:46AM -0400, Robert Haas wrote:
> On Mon, Mar 17, 2014 at 10:27 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
> > On Tue, Mar 18, 2014 at 10:24 AM, Fabrízio de Royes Mello
> > <fabriziomello@gmail.com> wrote:
> >>
> >> On Thu, Mar 13, 2014 at 10:22 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> >>> Well, it's fairly harmless, but it might not be a bad idea to tighten that
> >>> up.
> >> The attached patch tighten that up.
> > Hm... It might be interesting to include it in 9.4 IMO, somewhat
> > grouping with what has been done in a6542a4 for SET and ABORT.
> 
> Meh.  There will always be another thing we could squeeze in; I don't
> think this is particularly urgent, and it's late to the party.

Do we want this patch for 9.5?  It throws an error for invalid reloption
specifications.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +

On Thu, Aug 21, 2014 at 7:17 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Tue, Mar 18, 2014 at 09:11:46AM -0400, Robert Haas wrote:
>> On Mon, Mar 17, 2014 at 10:27 PM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>> > On Tue, Mar 18, 2014 at 10:24 AM, Fabrízio de Royes Mello
>> > <fabriziomello@gmail.com> wrote:
>> >>
>> >> On Thu, Mar 13, 2014 at 10:22 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> >>> Well, it's fairly harmless, but it might not be a bad idea to tighten that
>> >>> up.
>> >> The attached patch tighten that up.
>> > Hm... It might be interesting to include it in 9.4 IMO, somewhat
>> > grouping with what has been done in a6542a4 for SET and ABORT.
>>
>> Meh.  There will always be another thing we could squeeze in; I don't
>> think this is particularly urgent, and it's late to the party.
>
> Do we want this patch for 9.5?  It throws an error for invalid reloption
> specifications.

Fine with me.  But I have a vague recollection of seeing pg_upgrade
doing this on purpose to create TOAST tables or something... am I
misremembering?

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

On Fri, Aug 22, 2014 at 10:27:02AM -0400, Robert Haas wrote:
> On Thu, Aug 21, 2014 at 7:17 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > On Tue, Mar 18, 2014 at 09:11:46AM -0400, Robert Haas wrote:
> >> On Mon, Mar 17, 2014 at 10:27 PM, Michael Paquier
> >> <michael.paquier@gmail.com> wrote:
> >> > On Tue, Mar 18, 2014 at 10:24 AM, Fabrízio de Royes Mello
> >> > <fabriziomello@gmail.com> wrote:
> >> >>
> >> >> On Thu, Mar 13, 2014 at 10:22 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> >> >>> Well, it's fairly harmless, but it might not be a bad idea to tighten that
> >> >>> up.
> >> >> The attached patch tighten that up.
> >> > Hm... It might be interesting to include it in 9.4 IMO, somewhat
> >> > grouping with what has been done in a6542a4 for SET and ABORT.
> >>
> >> Meh.  There will always be another thing we could squeeze in; I don't
> >> think this is particularly urgent, and it's late to the party.
> >
> > Do we want this patch for 9.5?  It throws an error for invalid reloption
> > specifications.
> 
> Fine with me.  But I have a vague recollection of seeing pg_upgrade
> doing this on purpose to create TOAST tables or something... am I
> misremembering?

Yes, you remember well.  I will have to find a different way for
pg_upgrade to call a no-op ALTER TABLE, which is fine.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +

On Fri, Aug 22, 2014 at 12:53:30PM -0400, Bruce Momjian wrote:
> On Fri, Aug 22, 2014 at 10:27:02AM -0400, Robert Haas wrote:
> > On Thu, Aug 21, 2014 at 7:17 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > > On Tue, Mar 18, 2014 at 09:11:46AM -0400, Robert Haas wrote:
> > >> On Mon, Mar 17, 2014 at 10:27 PM, Michael Paquier
> > >> <michael.paquier@gmail.com> wrote:
> > >> > On Tue, Mar 18, 2014 at 10:24 AM, Fabrízio de Royes Mello
> > >> > <fabriziomello@gmail.com> wrote:
> > >> >>
> > >> >> On Thu, Mar 13, 2014 at 10:22 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> > >> >>> Well, it's fairly harmless, but it might not be a bad idea to tighten that
> > >> >>> up.
> > >> >> The attached patch tighten that up.
> > >> > Hm... It might be interesting to include it in 9.4 IMO, somewhat
> > >> > grouping with what has been done in a6542a4 for SET and ABORT.
> > >>
> > >> Meh.  There will always be another thing we could squeeze in; I don't
> > >> think this is particularly urgent, and it's late to the party.
> > >
> > > Do we want this patch for 9.5?  It throws an error for invalid reloption
> > > specifications.
> > 
> > Fine with me.  But I have a vague recollection of seeing pg_upgrade
> > doing this on purpose to create TOAST tables or something... am I
> > misremembering?
> 
> Yes, you remember well.  I will have to find a different way for
> pg_upgrade to call a no-op ALTER TABLE, which is fine.

Looking at the ALTER TABLE options, I am going to put this check in a
!IsBinaryUpgrade block so pg_upgrade can still use its trick.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +

On August 22, 2014 8:33:57 PM CEST, Bruce Momjian <bruce@momjian.us> wrote:
>On Fri, Aug 22, 2014 at 12:53:30PM -0400, Bruce Momjian wrote:
>> On Fri, Aug 22, 2014 at 10:27:02AM -0400, Robert Haas wrote:
>> > On Thu, Aug 21, 2014 at 7:17 PM, Bruce Momjian <bruce@momjian.us>
>wrote:
>> > > On Tue, Mar 18, 2014 at 09:11:46AM -0400, Robert Haas wrote:
>> > >> On Mon, Mar 17, 2014 at 10:27 PM, Michael Paquier
>> > >> <michael.paquier@gmail.com> wrote:
>> > >> > On Tue, Mar 18, 2014 at 10:24 AM, Fabrízio de Royes Mello
>> > >> > <fabriziomello@gmail.com> wrote:
>> > >> >>
>> > >> >> On Thu, Mar 13, 2014 at 10:22 AM, Robert Haas
><robertmhaas@gmail.com> wrote:
>> > >> >>> Well, it's fairly harmless, but it might not be a bad idea
>to tighten that
>> > >> >>> up.
>> > >> >> The attached patch tighten that up.
>> > >> > Hm... It might be interesting to include it in 9.4 IMO,
>somewhat
>> > >> > grouping with what has been done in a6542a4 for SET and ABORT.
>> > >>
>> > >> Meh.  There will always be another thing we could squeeze in; I
>don't
>> > >> think this is particularly urgent, and it's late to the party.
>> > >
>> > > Do we want this patch for 9.5?  It throws an error for invalid
>reloption
>> > > specifications.
>> > 
>> > Fine with me.  But I have a vague recollection of seeing pg_upgrade
>> > doing this on purpose to create TOAST tables or something... am I
>> > misremembering?
>> 
>> Yes, you remember well.  I will have to find a different way for
>> pg_upgrade to call a no-op ALTER TABLE, which is fine.
>
>Looking at the ALTER TABLE options, I am going to put this check in a
>!IsBinaryUpgrade block so pg_upgrade can still use it?

Why not simply not do anything?  This doesn't prevent any bugs and requiring pg-upgrade specific checks in there seems
absurd.Also somebody might use it for similar purposes.
 




--- 
Please excuse brevity and formatting - I am writing this on my mobile phone.

On Fri, Aug 22, 2014 at 2:33 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> Yes, you remember well.  I will have to find a different way for
>> pg_upgrade to call a no-op ALTER TABLE, which is fine.
>
> Looking at the ALTER TABLE options, I am going to put this check in a
> !IsBinaryUpgrade block so pg_upgrade can still use its trick.

-1, that's really ugly.

Maybe the right solution is to add a form of ALTER TABLE that is
specifically defined to do only this check.  This is an ongoing need,
so that might not be out of line.

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

On Fri, Aug 22, 2014 at 03:12:47PM -0400, Robert Haas wrote:
> On Fri, Aug 22, 2014 at 2:33 PM, Bruce Momjian <bruce@momjian.us> wrote:
> >> Yes, you remember well.  I will have to find a different way for
> >> pg_upgrade to call a no-op ALTER TABLE, which is fine.
> >
> > Looking at the ALTER TABLE options, I am going to put this check in a
> > !IsBinaryUpgrade block so pg_upgrade can still use its trick.
> 
> -1, that's really ugly.
> 
> Maybe the right solution is to add a form of ALTER TABLE that is
> specifically defined to do only this check.  This is an ongoing need,
> so that might not be out of line.

Ah, seems ALTER TABLE ... DROP CONSTRAINT IF EXISTS also works --- I
will use that.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +

On Fri, Aug 22, 2014 at 10:04:50PM -0400, Bruce Momjian wrote:
> On Fri, Aug 22, 2014 at 03:12:47PM -0400, Robert Haas wrote:
> > On Fri, Aug 22, 2014 at 2:33 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > >> Yes, you remember well.  I will have to find a different way for
> > >> pg_upgrade to call a no-op ALTER TABLE, which is fine.
> > >
> > > Looking at the ALTER TABLE options, I am going to put this check in a
> > > !IsBinaryUpgrade block so pg_upgrade can still use its trick.
> >
> > -1, that's really ugly.
> >
> > Maybe the right solution is to add a form of ALTER TABLE that is
> > specifically defined to do only this check.  This is an ongoing need,
> > so that might not be out of line.
>
> Ah, seems ALTER TABLE ... DROP CONSTRAINT IF EXISTS also works --- I
> will use that.

OK, attached patch applied, with pg_upgrade adjustments.  I didn't
think the original regression tests for this were necessary.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

<div dir="ltr"><div class="gmail_extra"><br />On Mon, Aug 25, 2014 at 6:07 PM, Bruce Momjian <<a
href="mailto:bruce@momjian.us">bruce@momjian.us</a>>wrote:<br />><br />> On Fri, Aug 22, 2014 at 10:04:50PM
-0400,Bruce Momjian wrote:<br />> > On Fri, Aug 22, 2014 at 03:12:47PM -0400, Robert Haas wrote:<br />> >
>On Fri, Aug 22, 2014 at 2:33 PM, Bruce Momjian <<a href="mailto:bruce@momjian.us">bruce@momjian.us</a>>
wrote:<br/>> > > >> Yes, you remember well.  I will have to find a different way for<br />> > >
>>pg_upgrade to call a no-op ALTER TABLE, which is fine.<br />> > > ><br />> > > >
Lookingat the ALTER TABLE options, I am going to put this check in a<br />> > > > !IsBinaryUpgrade block so
pg_upgradecan still use its trick.<br />> > ><br />> > > -1, that's really ugly.<br />> >
><br/>> > > Maybe the right solution is to add a form of ALTER TABLE that is<br />> > >
specificallydefined to do only this check.  This is an ongoing need,<br />> > > so that might not be out of
line.<br/>> ><br />> > Ah, seems ALTER TABLE ... DROP CONSTRAINT IF EXISTS also works --- I<br />> >
willuse that.<br />><br />> OK, attached patch applied, with pg_upgrade adjustments.  I didn't<br />> think
theoriginal regression tests for this were necessary.<br />><br /></div><div class="gmail_extra"><br />Hi,<br /><br
/></div><divclass="gmail_extra">Why this patch was reverted one day after applied [1]? I didn't see any discussion
aroundit.<br /></div><div class="gmail_extra"><br /></div><div class="gmail_extra">Regards,<br /><br /></div><div
class="gmail_extra">[1]<a
href="http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=6cb74a67e26523eb2408f441bfc589c80f76c465">http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=6cb74a67e26523eb2408f441bfc589c80f76c465</a><br
/><br/>--<br />Fabrízio de Royes Mello<br />Consultoria/Coaching PostgreSQL<br />>> Timbira: <a
href="http://www.timbira.com.br">http://www.timbira.com.br</a><br/>>> Blog: <a
href="http://fabriziomello.github.io">http://fabriziomello.github.io</a><br/>>> Linkedin: <a
href="http://br.linkedin.com/in/fabriziomello">http://br.linkedin.com/in/fabriziomello</a><br/>>> Twitter: <a
href="http://twitter.com/fabriziomello">http://twitter.com/fabriziomello</a><br/>>> Github: <a
href="http://github.com/fabriziomello">http://github.com/fabriziomello</a></div></div>

On 2015-08-26 16:24:31 -0300, Fabrízio de Royes Mello wrote:
> Why this patch was reverted one day after applied [1]? I didn't see any
> discussion around it.

http://www.postgresql.org/message-id/23918.1409010246@sss.pgh.pa.us

Fabrízio de Royes Mello wrote:

> Why this patch was reverted one day after applied [1]? I didn't see any
> discussion around it.

Contributors whose patches are getting committed should really subscribe
to pgsql-committers.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

<div dir="ltr"><br />On Wed, Aug 26, 2015 at 4:30 PM, Andres Freund <<a
href="mailto:andres@anarazel.de">andres@anarazel.de</a>>wrote:<br />><br />> On 2015-08-26 16:24:31 -0300,
Fabríziode Royes Mello wrote:<br />> > Why this patch was reverted one day after applied [1]? I didn't see any<br
/>>> discussion around it.<br />><br />> <a
href="http://www.postgresql.org/message-id/23918.1409010246@sss.pgh.pa.us">http://www.postgresql.org/message-id/23918.1409010246@sss.pgh.pa.us</a><br
/><br/><br />Thanks.... I'm not subscribed to pgsql-commiters so I didn't see it.<br /><br />--<br />Fabrízio de Royes
Mello<br/>Consultoria/Coaching PostgreSQL<br />>> Timbira: <a
href="http://www.timbira.com.br">http://www.timbira.com.br</a><br/>>> Blog: <a
href="http://fabriziomello.github.io">http://fabriziomello.github.io</a><br/>>> Linkedin: <a
href="http://br.linkedin.com/in/fabriziomello">http://br.linkedin.com/in/fabriziomello</a><br/>>> Twitter: <a
href="http://twitter.com/fabriziomello">http://twitter.com/fabriziomello</a><br/>>> Github: <a
href="http://github.com/fabriziomello">http://github.com/fabriziomello</a></div>

<div dir="ltr"><br />On Wed, Aug 26, 2015 at 4:31 PM, Alvaro Herrera <<a
href="mailto:alvherre@2ndquadrant.com">alvherre@2ndquadrant.com</a>>wrote:<br />><br />> Fabrízio de Royes
Mellowrote:<br />><br />> > Why this patch was reverted one day after applied [1]? I didn't see any<br />>
>discussion around it.<br />><br />> Contributors whose patches are getting committed should really
subscribe<br/>> to pgsql-committers.<br />><br /><br />Ok. I sent a subscribe to pgsql-committers.<br /><br
/>Thanks,<br/><br />--<br />Fabrízio de Royes Mello<br />Consultoria/Coaching PostgreSQL<br />>> Timbira: <a
href="http://www.timbira.com.br">http://www.timbira.com.br</a><br/>>> Blog: <a
href="http://fabriziomello.github.io">http://fabriziomello.github.io</a><br/>>> Linkedin: <a
href="http://br.linkedin.com/in/fabriziomello">http://br.linkedin.com/in/fabriziomello</a><br/>>> Twitter: <a
href="http://twitter.com/fabriziomello">http://twitter.com/fabriziomello</a><br/>>> Github: <a
href="http://github.com/fabriziomello">http://github.com/fabriziomello</a></div>

On Wed, Aug 26, 2015 at 3:31 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Fabrízio de Royes Mello wrote:
>
>> Why this patch was reverted one day after applied [1]? I didn't see any
>> discussion around it.
>
> Contributors whose patches are getting committed should really subscribe
> to pgsql-committers.

I would have thought discussion of committed patches should be moved
to -hackers.  The description for the -committers list says:

"Notification of git commits are sent to this list. Do not post here!"

So, it's understandable that people would not expect other traffic there.

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

Robert Haas wrote:
> On Wed, Aug 26, 2015 at 3:31 PM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
> > Fabrízio de Royes Mello wrote:
> >
> >> Why this patch was reverted one day after applied [1]? I didn't see any
> >> discussion around it.
> >
> > Contributors whose patches are getting committed should really subscribe
> > to pgsql-committers.
> 
> I would have thought discussion of committed patches should be moved
> to -hackers.

I agree, but it happens anyway quite frequently.  Since recently, I make
a point of changing the CC from -committers to -hackers, but due to
force of habit I often forget.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Fri, Sep  4, 2015 at 09:40:10AM +0900, Michael Paquier wrote:
>     Robert Haas wrote:
>     > On Wed, Aug 26, 2015 at 3:31 PM, Alvaro Herrera
>     > <alvherre@2ndquadrant.com> wrote:
>     > > Fabrízio de Royes Mello wrote:
>     > >
>     > >> Why this patch was reverted one day after applied [1]? I didn't see
>     any
>     > >> discussion around it.
>     > >
>     > > Contributors whose patches are getting committed should really
>     subscribe
>     > > to pgsql-committers.
>     >
>     > I would have thought discussion of committed patches should be moved
>     > to -hackers.
> 
>     I agree, but it happens anyway quite frequently.  Since recently, I make
>     a point of changing the CC from -committers to -hackers, but due to
>     force of habit I often forget.
> 
>  
> Noted. I usually don't do that.

I am thinking we should all agree if we should redirect commit comments
to hackers, or not, so we are consistent.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +