Re: [HACKERS] ALTER SYSTEM RESET?
On Wed, Sep 10, 2014 at 9:06 PM, Fujii Masao masao.fu...@gmail.com wrote: On Wed, Sep 3, 2014 at 12:08 AM, Christoph Berg c...@df7cb.de wrote: Re: Vik Fearing 2014-09-02 5405d2d9.9050...@dalibo.com Uhm, are we agreed on the decision on not to backpatch this? I would think this should have been part of the initial ALTER SYSTEM SET patch and thus should be backpatched to 9.4. I think it belongs in 9.4 as well, especially if we're having another beta. My original complaint was about 9.4, so I'd like to see it there, yes. ISTM that the consensus is to do the back-patch to 9.4. Does anyone object to the back-patch? If not, I will do that. Done because no one voiced objection against the back-patch. Regards, -- Fujii Masao -- 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] ALTER SYSTEM RESET?
On Wed, Sep 3, 2014 at 12:08 AM, Christoph Berg c...@df7cb.de wrote: Re: Vik Fearing 2014-09-02 5405d2d9.9050...@dalibo.com Uhm, are we agreed on the decision on not to backpatch this? I would think this should have been part of the initial ALTER SYSTEM SET patch and thus should be backpatched to 9.4. I think it belongs in 9.4 as well, especially if we're having another beta. My original complaint was about 9.4, so I'd like to see it there, yes. ISTM that the consensus is to do the back-patch to 9.4. Does anyone object to the back-patch? If not, I will do that. Regards, -- Fujii Masao -- 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] ALTER SYSTEM RESET?
On Mon, Sep 1, 2014 at 10:54 PM, Amit Kapila amit.kapil...@gmail.com wrote: On Mon, Sep 1, 2014 at 3:57 PM, Fujii Masao masao.fu...@gmail.com wrote: On Sat, Aug 30, 2014 at 12:27 PM, Amit Kapila amit.kapil...@gmail.com wrote: On Wed, Aug 27, 2014 at 7:16 PM, Fujii Masao masao.fu...@gmail.com wrote: The patch looks good to me. One minor comment is; probably you need to update the tab-completion code. Thanks for the review. I have updated the patch to support tab-completion. As this is a relatively minor change, I will mark it as Ready For Committer rather than Needs Review. Thanks for updating the patch! One more minor comment is; what about applying the following change for the tab-completion for RESET ALL? This causes the tab-completion of even ALTER SYSTEM SET to display all and that's strange. But the tab-completion of SET has already had the same problem. So I think that we can live with that. Right and I have checked that behaviour is same for other similar statements like Alter Database database_name SET config_var or Alter User user_name SET config_var. So, the change made by you is on similar lines. OK. Applied. Regards, -- Fujii Masao -- 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] ALTER SYSTEM RESET?
Fujii Masao wrote: On Mon, Sep 1, 2014 at 10:54 PM, Amit Kapila amit.kapil...@gmail.com wrote: On Mon, Sep 1, 2014 at 3:57 PM, Fujii Masao masao.fu...@gmail.com wrote: On Sat, Aug 30, 2014 at 12:27 PM, Amit Kapila amit.kapil...@gmail.com wrote: On Wed, Aug 27, 2014 at 7:16 PM, Fujii Masao masao.fu...@gmail.com wrote: The patch looks good to me. One minor comment is; probably you need to update the tab-completion code. Thanks for the review. I have updated the patch to support tab-completion. As this is a relatively minor change, I will mark it as Ready For Committer rather than Needs Review. Thanks for updating the patch! One more minor comment is; what about applying the following change for the tab-completion for RESET ALL? This causes the tab-completion of even ALTER SYSTEM SET to display all and that's strange. But the tab-completion of SET has already had the same problem. So I think that we can live with that. Right and I have checked that behaviour is same for other similar statements like Alter Database database_name SET config_var or Alter User user_name SET config_var. So, the change made by you is on similar lines. OK. Applied. Uhm, are we agreed on the decision on not to backpatch this? I would think this should have been part of the initial ALTER SYSTEM SET patch and thus should be backpatched to 9.4. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- 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] ALTER SYSTEM RESET?
On 09/02/2014 04:12 PM, Alvaro Herrera wrote: Fujii Masao wrote: On Mon, Sep 1, 2014 at 10:54 PM, Amit Kapila amit.kapil...@gmail.com wrote: On Mon, Sep 1, 2014 at 3:57 PM, Fujii Masao masao.fu...@gmail.com wrote: On Sat, Aug 30, 2014 at 12:27 PM, Amit Kapila amit.kapil...@gmail.com wrote: On Wed, Aug 27, 2014 at 7:16 PM, Fujii Masao masao.fu...@gmail.com wrote: The patch looks good to me. One minor comment is; probably you need to update the tab-completion code. Thanks for the review. I have updated the patch to support tab-completion. As this is a relatively minor change, I will mark it as Ready For Committer rather than Needs Review. Thanks for updating the patch! One more minor comment is; what about applying the following change for the tab-completion for RESET ALL? This causes the tab-completion of even ALTER SYSTEM SET to display all and that's strange. But the tab-completion of SET has already had the same problem. So I think that we can live with that. Right and I have checked that behaviour is same for other similar statements like Alter Database database_name SET config_var or Alter User user_name SET config_var. So, the change made by you is on similar lines. OK. Applied. Uhm, are we agreed on the decision on not to backpatch this? I would think this should have been part of the initial ALTER SYSTEM SET patch and thus should be backpatched to 9.4. I think it belongs in 9.4 as well, especially if we're having another beta. -- Vik -- 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] ALTER SYSTEM RESET?
Re: Vik Fearing 2014-09-02 5405d2d9.9050...@dalibo.com Uhm, are we agreed on the decision on not to backpatch this? I would think this should have been part of the initial ALTER SYSTEM SET patch and thus should be backpatched to 9.4. I think it belongs in 9.4 as well, especially if we're having another beta. My original complaint was about 9.4, so I'd like to see it there, yes. IMHO it doesn't make sense to ship a crippled version first, let users get used to the fact that (RE)SET and ALTER SYSTEM (RE)SET behave differently, and then ship the full feature in 9.5 later. Also, this should be something that is trivially to test, so there's little chance of slipping bugs into 9.4 that would go unnoticed. Christoph -- c...@df7cb.de | http://www.df7cb.de/ -- 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] ALTER SYSTEM RESET?
On Sat, Aug 30, 2014 at 12:27 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Wed, Aug 27, 2014 at 7:16 PM, Fujii Masao masao.fu...@gmail.com wrote:
The patch looks good to me. One minor comment is; probably you need to
update the tab-completion code.
Thanks for the review. I have updated the patch to support
tab-completion.
As this is a relatively minor change, I will mark it as
Ready For Committer rather than Needs Review.
Thanks for updating the patch!
One more minor comment is; what about applying the following change
for the tab-completion for RESET ALL? This causes the tab-completion of
even ALTER SYSTEM SET to display all and that's strange. But
the tab-completion of SET has already had the same problem. So
I think that we can live with that. Attached is the patch that I added
the following change onto your patch. Barring any objection, I will commit
the patch.
@@ -545,7 +545,8 @@ static const SchemaQuery Query_for_list_of_matviews = {
SELECT name FROM \
(SELECT pg_catalog.lower(name) AS name FROM pg_catalog.pg_settings \
WHERE context != 'internal') ss \
- WHERE substring(name,1,%d)='%s'
+ WHERE substring(name,1,%d)='%s'\
+ UNION ALL SELECT 'all' ss
Regards,
--
Fujii Masao
*** a/doc/src/sgml/ref/alter_system.sgml
--- b/doc/src/sgml/ref/alter_system.sgml
***
*** 22,27 PostgreSQL documentation
--- 22,30
refsynopsisdiv
synopsis
ALTER SYSTEM SET replaceable class=PARAMETERconfiguration_parameter/replaceable { TO | = } { replaceable class=PARAMETERvalue/replaceable | 'replaceable class=PARAMETERvalue/replaceable' | DEFAULT }
+
+ ALTER SYSTEM RESET replaceable class=PARAMETERconfiguration_parameter/replaceable
+ ALTER SYSTEM RESET ALL
/synopsis
/refsynopsisdiv
***
*** 30,39 ALTER SYSTEM SET replaceable class=PARAMETERconfiguration_parameter/replace
para
commandALTER SYSTEM/command writes the configuration parameter
!values to the filenamepostgresql.auto.conf/filename file. With
!literalDEFAULT/literal, it removes a configuration entry from
!filenamepostgresql.auto.conf/filename file. The values will be
!effective after reload of server configuration (SIGHUP) or in next
server start based on the type of configuration parameter modified.
/para
--- 33,44
para
commandALTER SYSTEM/command writes the configuration parameter
!values to the filenamepostgresql.auto.conf/filename file.
!Setting the parameter to literalDEFAULT/literal, or using the
!commandRESET/command variant, removes the configuration entry from
!filenamepostgresql.auto.conf/filename file. Use literalRESET
!ALL/literal to clear all configuration entries. The values will
!be effective after reload of server configuration (SIGHUP) or in next
server start based on the type of configuration parameter modified.
/para
*** a/src/backend/parser/gram.y
--- b/src/backend/parser/gram.y
***
*** 411,417 static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
%type istmt insert_rest
! %type vsetstmt generic_set set_rest set_rest_more SetResetClause FunctionSetResetClause
%type node TableElement TypedTableElement ConstraintElem TableFuncElement
%type node columnDef columnOptions
--- 411,418
%type istmt insert_rest
! %type vsetstmt generic_set set_rest set_rest_more generic_reset reset_rest
! SetResetClause FunctionSetResetClause
%type node TableElement TypedTableElement ConstraintElem TableFuncElement
%type node columnDef columnOptions
***
*** 1579,1617 NonReservedWord_or_Sconst:
;
VariableResetStmt:
! RESET var_name
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-kind = VAR_RESET;
! n-name = $2;
! $$ = (Node *) n;
}
! | RESET TIME ZONE
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-kind = VAR_RESET;
! n-name = timezone;
! $$ = (Node *) n;
}
! | RESET TRANSACTION ISOLATION LEVEL
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-kind = VAR_RESET;
! n-name = transaction_isolation;
! $$ = (Node *) n;
}
! | RESET SESSION AUTHORIZATION
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-kind = VAR_RESET;
! n-name = session_authorization;
! $$ = (Node *) n;
}
! | RESET ALL
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-kind = VAR_RESET_ALL;
! $$ = (Node *) n;
}
;
--- 1580,1626
;
VariableResetStmt:
! RESET reset_rest { $$ = (Node *) $2; }
! ;
!
! reset_rest:
! generic_reset { $$ = $1; }
! | TIME ZONE
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-kind = VAR_RESET;
! n-name = timezone;
! $$ = n;
}
! | TRANSACTION ISOLATION LEVEL
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-kind
Re: [HACKERS] ALTER SYSTEM RESET?
On Mon, Sep 1, 2014 at 3:57 PM, Fujii Masao masao.fu...@gmail.com wrote: On Sat, Aug 30, 2014 at 12:27 PM, Amit Kapila amit.kapil...@gmail.com wrote: On Wed, Aug 27, 2014 at 7:16 PM, Fujii Masao masao.fu...@gmail.com wrote: The patch looks good to me. One minor comment is; probably you need to update the tab-completion code. Thanks for the review. I have updated the patch to support tab-completion. As this is a relatively minor change, I will mark it as Ready For Committer rather than Needs Review. Thanks for updating the patch! One more minor comment is; what about applying the following change for the tab-completion for RESET ALL? This causes the tab-completion of even ALTER SYSTEM SET to display all and that's strange. But the tab-completion of SET has already had the same problem. So I think that we can live with that. Right and I have checked that behaviour is same for other similar statements like Alter Database database_name SET config_var or Alter User user_name SET config_var. So, the change made by you is on similar lines. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Re: [HACKERS] ALTER SYSTEM RESET?
On Wed, Aug 27, 2014 at 7:16 PM, Fujii Masao masao.fu...@gmail.com wrote: The patch looks good to me. One minor comment is; probably you need to update the tab-completion code. Thanks for the review. I have updated the patch to support tab-completion. As this is a relatively minor change, I will mark it as Ready For Committer rather than Needs Review. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com alter_system_reset.v5.patch Description: Binary data -- 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] ALTER SYSTEM RESET?
On Mon, Aug 25, 2014 at 1:34 PM, Amit Kapila amit.kapil...@gmail.com wrote: On Wed, Jul 30, 2014 at 9:11 AM, Amit Kapila amit.kapil...@gmail.com wrote: I have verified the patch and found that it works well for all scenario's. Few minor suggestions: 1. !values to the filenamepostgresql.auto.conf/filename file. !Setting the parameter to literalDEFAULT/literal, or using the !commandRESET/command variant, removes the configuration entry from It would be better if we can write a separate line for RESET ALL as is written in case of both Alter Database and Alter Role in their respective documentation. 2. ! %type vsetstmt generic_set set_rest set_rest_more generic_reset reset_rest SetResetClause FunctionSetResetClause Good to break it into 2 lines. 3. I think we can add some text on top of function AlterSystemSetConfigFile() to explain functionality w.r.t reset all. I have updated the patch to address the above points. I will mark this patch as Ready For Committer as most of the review comments were already addressed by Vik and remaining I have addressed in attached patch. The patch looks good to me. One minor comment is; probably you need to update the tab-completion code. Regards, -- Fujii Masao -- 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] ALTER SYSTEM RESET?
On Wed, Jul 30, 2014 at 9:11 AM, Amit Kapila amit.kapil...@gmail.com wrote: I have verified the patch and found that it works well for all scenario's. Few minor suggestions: 1. !values to the filenamepostgresql.auto.conf/filename file. !Setting the parameter to literalDEFAULT/literal, or using the !commandRESET/command variant, removes the configuration entry from It would be better if we can write a separate line for RESET ALL as is written in case of both Alter Database and Alter Role in their respective documentation. 2. ! %type vsetstmt generic_set set_rest set_rest_more generic_reset reset_rest SetResetClause FunctionSetResetClause Good to break it into 2 lines. 3. I think we can add some text on top of function AlterSystemSetConfigFile() to explain functionality w.r.t reset all. I have updated the patch to address the above points. I will mark this patch as Ready For Committer as most of the review comments were already addressed by Vik and remaining I have addressed in attached patch. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com alter_system_reset.v4.patch Description: Binary data -- 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] ALTER SYSTEM RESET?
On Thu, Jun 26, 2014 at 8:17 PM, Vik Fearing vik.fear...@dalibo.com wrote: I didn't quite follow your ALTER TABLE example because I don't think it's necessary, I was asking to split the ALTER SYSTEM command like it's there for ALTER TABLE (AlterTableStmt: ALTER TABLE relation_expr alter_table_cmds). It would have make adding further commands to ALTER SYSTEM bit simpler and systemetic. However as there is no correctness issue here, so lets leave it like you have currently done in patch. I have verified the patch and found that it works well for all scenario's. Few minor suggestions: 1. !values to the filenamepostgresql.auto.conf/filename file. !Setting the parameter to literalDEFAULT/literal, or using the !commandRESET/command variant, removes the configuration entry from It would be better if we can write a separate line for RESET ALL as is written in case of both Alter Database and Alter Role in their respective documentation. 2. ! %type vsetstmt generic_set set_rest set_rest_more generic_reset reset_rest SetResetClause FunctionSetResetClause Good to break it into 2 lines. 3. I think we can add some text on top of function AlterSystemSetConfigFile() to explain functionality w.r.t reset all. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Re: [HACKERS] ALTER SYSTEM RESET?
Re: Vik Fearing 2014-06-27 53ad15f7.2060...@dalibo.com On 06/27/2014 08:49 AM, Vik Fearing wrote: This third patch reformats the documentation in the way I expected it to be committed. Amit, I added this to the next commitfest with your name as reviewer. https://commitfest.postgresql.org/action/patch_view?id=1495 Please update the status as you see fit. Isn't this 9.4 material? It seems like an oversight in the ALTER SYSTEM implementation, and people will be expecting ALTER SYTEM (RE)SET guc to just work like (RE)SET guc. It was mentioned by Alvaro there: http://www.postgresql.org/message-id/20130802173458.go5...@eldon.alvh.no-ip.org Christoph -- c...@df7cb.de | http://www.df7cb.de/ -- 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] ALTER SYSTEM RESET?
On Sat, Jun 28, 2014 at 10:38 PM, Christoph Berg c...@df7cb.de wrote: Re: Vik Fearing 2014-06-27 53ad15f7.2060...@dalibo.com Amit, I added this to the next commitfest with your name as reviewer. https://commitfest.postgresql.org/action/patch_view?id=1495 Please update the status as you see fit. Isn't this 9.4 material? I think it's late for adding new feature/sub-feature/minor enhancement in 9.4, unless without that base feature won't work. Isn't your use case addressed by alternative suggested by me upthread? With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Re: [HACKERS] ALTER SYSTEM RESET?
On 06/27/2014 06:22 AM, Amit Kapila wrote:
On Thu, Jun 26, 2014 at 8:17 PM, Vik Fearing vik.fear...@dalibo.com
mailto:vik.fear...@dalibo.com wrote:
On 06/26/2014 05:07 AM, Amit Kapila wrote:
I think it will make sense if we support RESET ALL as well similar
to Alter Database .. RESET ALL syntax. Do you see any reason
why we shouldn't support RESET ALL syntax for Alter System?
Yes, that makes sense. I've added that in the attached version 2 of the
patch.
I think the idea used in patch to implement RESET ALL is sane. In passing
by, I noticed that modified lines in .sgml have crossed 80 char
boundary which
is generally preferred to be maintained..
Refer below modification.
!values to the filenamepostgresql.auto.conf/filename file.
Setting the parameter to
!literalDEFAULT/literal, or using the commandRESET/command
variant, removes the configuration entry from
I did that on purpose so that it's easy for a reviewer/committer to see
what changed.
This third patch reformats the documentation in the way I expected it to
be committed.
--
Vik
*** a/doc/src/sgml/ref/alter_system.sgml
--- b/doc/src/sgml/ref/alter_system.sgml
***
*** 22,27 PostgreSQL documentation
--- 22,30
refsynopsisdiv
synopsis
ALTER SYSTEM SET replaceable class=PARAMETERconfiguration_parameter/replaceable { TO | = } { replaceable class=PARAMETERvalue/replaceable | 'replaceable class=PARAMETERvalue/replaceable' | DEFAULT }
+
+ ALTER SYSTEM RESET replaceable class=PARAMETERconfiguration_parameter/replaceable
+ ALTER SYSTEM RESET ALL
/synopsis
/refsynopsisdiv
***
*** 30,37 ALTER SYSTEM SET replaceable class=PARAMETERconfiguration_parameter/replace
para
commandALTER SYSTEM/command writes the configuration parameter
!values to the filenamepostgresql.auto.conf/filename file. With
!literalDEFAULT/literal, it removes a configuration entry from
filenamepostgresql.auto.conf/filename file. The values will be
effective after reload of server configuration (SIGHUP) or in next
server start based on the type of configuration parameter modified.
--- 33,41
para
commandALTER SYSTEM/command writes the configuration parameter
!values to the filenamepostgresql.auto.conf/filename file.
!Setting the parameter to literalDEFAULT/literal, or using the
!commandRESET/command variant, removes the configuration entry from
filenamepostgresql.auto.conf/filename file. The values will be
effective after reload of server configuration (SIGHUP) or in next
server start based on the type of configuration parameter modified.
*** a/src/backend/parser/gram.y
--- b/src/backend/parser/gram.y
***
*** 401,407 static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
%type istmt insert_rest
! %type vsetstmt generic_set set_rest set_rest_more SetResetClause FunctionSetResetClause
%type node TableElement TypedTableElement ConstraintElem TableFuncElement
%type node columnDef columnOptions
--- 401,407
%type istmt insert_rest
! %type vsetstmt generic_set set_rest set_rest_more generic_reset reset_rest SetResetClause FunctionSetResetClause
%type node TableElement TypedTableElement ConstraintElem TableFuncElement
%type node columnDef columnOptions
***
*** 1567,1605 NonReservedWord_or_Sconst:
;
VariableResetStmt:
! RESET var_name
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-kind = VAR_RESET;
! n-name = $2;
! $$ = (Node *) n;
}
! | RESET TIME ZONE
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-kind = VAR_RESET;
! n-name = timezone;
! $$ = (Node *) n;
}
! | RESET TRANSACTION ISOLATION LEVEL
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-kind = VAR_RESET;
! n-name = transaction_isolation;
! $$ = (Node *) n;
}
! | RESET SESSION AUTHORIZATION
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-kind = VAR_RESET;
! n-name = session_authorization;
! $$ = (Node *) n;
}
! | RESET ALL
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-kind = VAR_RESET_ALL;
! $$ = (Node *) n;
}
;
--- 1567,1613
;
VariableResetStmt:
! RESET reset_rest { $$ = (Node *) $2; }
! ;
!
! reset_rest:
! generic_reset { $$ = $1; }
! | TIME ZONE
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-kind = VAR_RESET;
! n-name = timezone;
! $$ = n;
}
! | TRANSACTION ISOLATION LEVEL
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-kind = VAR_RESET;
! n-name = transaction_isolation;
! $$ = n;
}
! | SESSION AUTHORIZATION
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-kind = VAR_RESET;
! n-name = session_authorization;
!
Re: [HACKERS] ALTER SYSTEM RESET?
On 06/27/2014 08:49 AM, Vik Fearing wrote: This third patch reformats the documentation in the way I expected it to be committed. Amit, I added this to the next commitfest with your name as reviewer. https://commitfest.postgresql.org/action/patch_view?id=1495 Please update the status as you see fit. -- Vik -- 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] ALTER SYSTEM RESET?
On Fri, Jun 27, 2014 at 12:27 PM, Vik Fearing vik.fear...@dalibo.com wrote: On 06/27/2014 08:49 AM, Vik Fearing wrote: This third patch reformats the documentation in the way I expected it to be committed. Amit, I added this to the next commitfest with your name as reviewer. No issues, I will review it in next CF. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Re: [HACKERS] ALTER SYSTEM RESET?
Re: Amit Kapila 2014-06-26 caa4ek1+zt_uo-z7wjp2yznv7aytxgbqgp23wcmpub9sdmgy...@mail.gmail.com On Wed, Jun 25, 2014 at 9:56 PM, Vik Fearing vik.fear...@dalibo.com wrote: On 06/25/2014 03:04 PM, Amit Kapila wrote: Currently you can achieve that by ALTER SYSTEM RESET guc = Default;. However it will be good to have support for RESET as well. I think it should not be too complicated to implement that syntax, I personally don't have bandwidth to it immediately, but I would like to take care of it unless you or someone wants to do it by the time I get some bandwidth. Would something like this suffice? I think it will make sense if we support RESET ALL as well similar to Alter Database .. RESET ALL syntax. Do you see any reason why we shouldn't support RESET ALL syntax for Alter System? RESET ALL would definitely be useful to have as well. Christoph -- c...@df7cb.de | http://www.df7cb.de/ -- 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] ALTER SYSTEM RESET?
On 06/26/2014 05:07 AM, Amit Kapila wrote:
On Wed, Jun 25, 2014 at 9:56 PM, Vik Fearing vik.fear...@dalibo.com
mailto:vik.fear...@dalibo.com wrote:
On 06/25/2014 03:04 PM, Amit Kapila wrote:
Currently you can achieve that by
ALTER SYSTEM RESET guc = Default;.
However it will be good to have support for RESET as well. I think it
should not be too complicated to implement that syntax, I personally
don't have bandwidth to it immediately, but I would like to take care
of it unless you or someone wants to do it by the time I get some
bandwidth.
Would something like this suffice?
I think it will make sense if we support RESET ALL as well similar
to Alter Database .. RESET ALL syntax. Do you see any reason
why we shouldn't support RESET ALL syntax for Alter System?
Yes, that makes sense. I've added that in the attached version 2 of the
patch.
About patch:
+ | ALTER SYSTEM_P RESET var_name
+ {
+ AlterSystemStmt *n = makeNode(AlterSystemStmt);
+ n-setstmt = makeNode(VariableSetStmt);
+ n-setstmt-kind = VAR_RESET;
+ n-setstmt-name = $4;
+ $ = (Node *)n;
+ }
I think it would be better to have ALTER SYSTEM_P as generic and
then SET | RESET as different versions, something like below:
| SET reloptions
{
AlterTableCmd *n = makeNode(AlterTableCmd);
n-subtype = AT_SetRelOptions;
n-def = (Node *)$2;
$$ = (Node *)n;
}
/* ALTER TABLE name RESET (...) */
| RESET reloptions
{
AlterTableCmd *n = makeNode(AlterTableCmd);
n-subtype = AT_ResetRelOptions;
n-def = (Node *)$2;
$$ = (Node *)n;
}
Another point is that if we decide to support RESET ALL syntax, then
we might want reuse VariableResetStmt, may be by breaking into
generic and specific like we have done for generic_set.
I didn't quite follow your ALTER TABLE example because I don't think
it's necessary, but I did split out VariableResetStmt like you suggested
because I think that is indeed cleaner.
Thanks for working on patch.
You're welcome.
--
Vik
*** a/doc/src/sgml/ref/alter_system.sgml
--- b/doc/src/sgml/ref/alter_system.sgml
***
*** 22,27 PostgreSQL documentation
--- 22,30
refsynopsisdiv
synopsis
ALTER SYSTEM SET replaceable class=PARAMETERconfiguration_parameter/replaceable { TO | = } { replaceable class=PARAMETERvalue/replaceable | 'replaceable class=PARAMETERvalue/replaceable' | DEFAULT }
+
+ ALTER SYSTEM RESET replaceable class=PARAMETERconfiguration_parameter/replaceable
+ ALTER SYSTEM RESET ALL
/synopsis
/refsynopsisdiv
***
*** 30,37 ALTER SYSTEM SET replaceable class=PARAMETERconfiguration_parameter/replace
para
commandALTER SYSTEM/command writes the configuration parameter
!values to the filenamepostgresql.auto.conf/filename file. With
!literalDEFAULT/literal, it removes a configuration entry from
filenamepostgresql.auto.conf/filename file. The values will be
effective after reload of server configuration (SIGHUP) or in next
server start based on the type of configuration parameter modified.
--- 33,40
para
commandALTER SYSTEM/command writes the configuration parameter
!values to the filenamepostgresql.auto.conf/filename file. Setting the parameter to
!literalDEFAULT/literal, or using the commandRESET/command variant, removes the configuration entry from
filenamepostgresql.auto.conf/filename file. The values will be
effective after reload of server configuration (SIGHUP) or in next
server start based on the type of configuration parameter modified.
*** a/src/backend/parser/gram.y
--- b/src/backend/parser/gram.y
***
*** 401,407 static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
%type istmt insert_rest
! %type vsetstmt generic_set set_rest set_rest_more SetResetClause FunctionSetResetClause
%type node TableElement TypedTableElement ConstraintElem TableFuncElement
%type node columnDef columnOptions
--- 401,407
%type istmt insert_rest
! %type vsetstmt generic_set set_rest set_rest_more generic_reset reset_rest SetResetClause FunctionSetResetClause
%type node TableElement TypedTableElement ConstraintElem TableFuncElement
%type node columnDef columnOptions
***
*** 1567,1605 NonReservedWord_or_Sconst:
;
VariableResetStmt:
! RESET var_name
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-kind = VAR_RESET;
! n-name = $2;
! $$ = (Node *) n;
}
! | RESET TIME ZONE
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-kind = VAR_RESET;
! n-name = timezone;
! $$ = (Node *) n;
}
! | RESET TRANSACTION ISOLATION LEVEL
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-kind = VAR_RESET;
! n-name = transaction_isolation;
! $$ = (Node *) n;
}
! | RESET SESSION AUTHORIZATION
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-kind =
Re: [HACKERS] ALTER SYSTEM RESET?
On Thu, Jun 26, 2014 at 8:17 PM, Vik Fearing vik.fear...@dalibo.com wrote: On 06/26/2014 05:07 AM, Amit Kapila wrote: I think it will make sense if we support RESET ALL as well similar to Alter Database .. RESET ALL syntax. Do you see any reason why we shouldn't support RESET ALL syntax for Alter System? Yes, that makes sense. I've added that in the attached version 2 of the patch. I think the idea used in patch to implement RESET ALL is sane. In passing by, I noticed that modified lines in .sgml have crossed 80 char boundary which is generally preferred to be maintained.. Refer below modification. !values to the filenamepostgresql.auto.conf/filename file. Setting the parameter to !literalDEFAULT/literal, or using the commandRESET/command variant, removes the configuration entry from With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
[HACKERS] ALTER SYSTEM RESET?
Hi, is there a reason there's no ALTER SYSTEM RESET? The natural idiom to reset SET statements is RESET guc;, I don't think SET guc = default; is in use much, so ALTER SYSTEM RESET guc; would be the natural way to try. Also, ALTER SYSTEM SET/RESET seems to be what oracle does: http://docs.oracle.com/cd/E11882_01/server.112/e40402/initparams004.htm#REFRN00102 Christoph -- c...@df7cb.de | http://www.df7cb.de/ -- 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] ALTER SYSTEM RESET?
On Wed, Jun 25, 2014 at 6:20 PM, Christoph Berg c...@df7cb.de wrote: Hi, is there a reason there's no ALTER SYSTEM RESET? The natural idiom to reset SET statements is RESET guc;, I don't think SET guc = default; is in use much, so ALTER SYSTEM RESET guc; would be the natural way to try. Currently you can achieve that by ALTER SYSTEM RESET guc = Default;. However it will be good to have support for RESET as well. I think it should not be too complicated to implement that syntax, I personally don't have bandwidth to it immediately, but I would like to take care of it unless you or someone wants to do it by the time I get some bandwidth. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Re: [HACKERS] ALTER SYSTEM RESET?
On Wed, Jun 25, 2014 at 10:04 AM, Amit Kapila amit.kapil...@gmail.com wrote: On Wed, Jun 25, 2014 at 6:20 PM, Christoph Berg c...@df7cb.de wrote: Hi, is there a reason there's no ALTER SYSTEM RESET? The natural idiom to reset SET statements is RESET guc;, I don't think SET guc = default; is in use much, so ALTER SYSTEM RESET guc; would be the natural way to try. Currently you can achieve that by ALTER SYSTEM RESET guc = Default;. However it will be good to have support for RESET as well. I think it should not be too complicated to implement that syntax, I personally don't have bandwidth to it immediately, but I would like to take care of it unless you or someone wants to do it by the time I get some bandwidth. I have some time then I can provide a patch in a few days... Is ok for you guys? Regards, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Timbira: http://www.timbira.com.br Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello
Re: [HACKERS] ALTER SYSTEM RESET?
On 06/25/2014 03:04 PM, Amit Kapila wrote:
On Wed, Jun 25, 2014 at 6:20 PM, Christoph Berg c...@df7cb.de
mailto:c...@df7cb.de wrote:
Hi,
is there a reason there's no ALTER SYSTEM RESET?
The natural idiom to reset SET statements is RESET guc;, I don't
think SET guc = default; is in use much, so ALTER SYSTEM RESET guc;
would be the natural way to try.
Currently you can achieve that by
ALTER SYSTEM RESET guc = Default;.
However it will be good to have support for RESET as well. I think it
should not be too complicated to implement that syntax, I personally
don't have bandwidth to it immediately, but I would like to take care
of it unless you or someone wants to do it by the time I get some
bandwidth.
Would something like this suffice?
--
Vik
*** a/doc/src/sgml/ref/alter_system.sgml
--- b/doc/src/sgml/ref/alter_system.sgml
***
*** 22,27 PostgreSQL documentation
--- 22,28
refsynopsisdiv
synopsis
ALTER SYSTEM SET replaceable class=PARAMETERconfiguration_parameter/replaceable { TO | = } { replaceable class=PARAMETERvalue/replaceable | 'replaceable class=PARAMETERvalue/replaceable' | DEFAULT }
+ ALTER SYSTEM RESET replaceable class=PARAMETERconfiguration_parameter/replaceable
/synopsis
/refsynopsisdiv
***
*** 30,37 ALTER SYSTEM SET replaceable class=PARAMETERconfiguration_parameter/replace
para
commandALTER SYSTEM/command writes the configuration parameter
!values to the filenamepostgresql.auto.conf/filename file. With
!literalDEFAULT/literal, it removes a configuration entry from
filenamepostgresql.auto.conf/filename file. The values will be
effective after reload of server configuration (SIGHUP) or in next
server start based on the type of configuration parameter modified.
--- 31,38
para
commandALTER SYSTEM/command writes the configuration parameter
!values to the filenamepostgresql.auto.conf/filename file. Setting the parameter to
!literalDEFAULT/literal, or using the commandRESET/command variant, removes the configuration entry from
filenamepostgresql.auto.conf/filename file. The values will be
effective after reload of server configuration (SIGHUP) or in next
server start based on the type of configuration parameter modified.
*** a/src/backend/parser/gram.y
--- b/src/backend/parser/gram.y
***
*** 8486,8491 AlterSystemStmt:
--- 8486,8499
n-setstmt = $4;
$$ = (Node *)n;
}
+ | ALTER SYSTEM_P RESET var_name
+ {
+ AlterSystemStmt *n = makeNode(AlterSystemStmt);
+ n-setstmt = makeNode(VariableSetStmt);
+ n-setstmt-kind = VAR_RESET;
+ n-setstmt-name = $4;
+ $$ = (Node *)n;
+ }
;
*** a/src/backend/utils/misc/guc.c
--- b/src/backend/utils/misc/guc.c
***
*** 6720,6725 AlterSystemSetConfigFile(AlterSystemStmt *altersysstmt)
--- 6720,6726
break;
case VAR_SET_DEFAULT:
+ case VAR_RESET:
value = NULL;
break;
default:
--
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] ALTER SYSTEM RESET?
On Wed, Jun 25, 2014 at 1:26 PM, Vik Fearing vik.fear...@dalibo.com wrote: On 06/25/2014 03:04 PM, Amit Kapila wrote: On Wed, Jun 25, 2014 at 6:20 PM, Christoph Berg c...@df7cb.de mailto:c...@df7cb.de wrote: Hi, is there a reason there's no ALTER SYSTEM RESET? The natural idiom to reset SET statements is RESET guc;, I don't think SET guc = default; is in use much, so ALTER SYSTEM RESET guc; would be the natural way to try. Currently you can achieve that by ALTER SYSTEM RESET guc = Default;. However it will be good to have support for RESET as well. I think it should not be too complicated to implement that syntax, I personally don't have bandwidth to it immediately, but I would like to take care of it unless you or someone wants to do it by the time I get some bandwidth. Would something like this suffice? Is fine to me... -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Timbira: http://www.timbira.com.br Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello
Re: [HACKERS] ALTER SYSTEM RESET?
On Wed, Jun 25, 2014 at 9:56 PM, Vik Fearing vik.fear...@dalibo.com wrote:
On 06/25/2014 03:04 PM, Amit Kapila wrote:
Currently you can achieve that by
ALTER SYSTEM RESET guc = Default;.
However it will be good to have support for RESET as well. I think it
should not be too complicated to implement that syntax, I personally
don't have bandwidth to it immediately, but I would like to take care
of it unless you or someone wants to do it by the time I get some
bandwidth.
Would something like this suffice?
I think it will make sense if we support RESET ALL as well similar
to Alter Database .. RESET ALL syntax. Do you see any reason
why we shouldn't support RESET ALL syntax for Alter System?
About patch:
+ | ALTER SYSTEM_P RESET var_name
+ {
+ AlterSystemStmt *n = makeNode(AlterSystemStmt);
+ n-setstmt = makeNode(VariableSetStmt);
+ n-setstmt-kind = VAR_RESET;
+ n-setstmt-name = $4;
+ $ = (Node *)n;
+ }
I think it would be better to have ALTER SYSTEM_P as generic and
then SET | RESET as different versions, something like below:
| SET reloptions
{
AlterTableCmd *n = makeNode(AlterTableCmd);
n-subtype = AT_SetRelOptions;
n-def = (Node *)$2;
$$ = (Node *)n;
}
/* ALTER TABLE name RESET (...) */
| RESET reloptions
{
AlterTableCmd *n = makeNode(AlterTableCmd);
n-subtype = AT_ResetRelOptions;
n-def = (Node *)$2;
$$ = (Node *)n;
}
Another point is that if we decide to support RESET ALL syntax, then
we might want reuse VariableResetStmt, may be by breaking into
generic and specific like we have done for generic_set.
Thanks for working on patch.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
