Re: BUG #15646: Inconsistent behavior for current_setting/set_config
On Tuesday, February 26, 2019, Eugen Konkov wrote: > If I use 'false' then transaction will not have effect, because I set the > value to session? > The current transaction is always affected. True meansonly; false causes the change to persist beyond, for the life of the session. Davis J.
Re: BUG #15646: Inconsistent behavior for current_setting/set_config
Hello Documentation has no description how 'false' value for 'is_local' parameter interact with transaction Do I understand correct? https://www.postgresql.org/docs/11/functions-admin.html#FUNCTIONS-ADMIN-SET >set_config sets the parameter setting_name to new_value. If is_local is true, >the new value will only apply to the current transaction. If you want the new >value to apply for the current session, use false instead. If I use 'false' then transaction will not have effect, because I set the value to session? tucha=> select current_setting( 'my.app_period', true ); current_setting - (1 row) tucha=> begin; BEGIN tucha=> select set_config( 'my.app_period', tstzrange( '-infinity', 'infinity' )::text, false ); set_config -- [-infinity,infinity) (1 row) tucha=> rollback; ROLLBACK NOTICE: session is rolled back and session value is rolled back despite on that I did not use 'true' as parameter for local: tucha=> select current_setting( 'my.app_period', true ); current_setting - (1 row) tucha=> begin; BEGIN tucha=> select set_config( 'my.app_period', tstzrange( '-infinity', 'infinity' )::text, false ); set_config -- [-infinity,infinity) (1 row) tucha=> commit; COMMIT When I commit then the value is applied to session: tucha=> select current_setting( 'my.app_period', true ); current_setting -- [-infinity,infinity) (1 row) -- Best regards, Eugen Konkov
Re: BUG #15646: Inconsistent behavior for current_setting/set_config
Hello, Not sure I should open new issue or continue this one. select set_config( 'my.some_conf', 'value', true ); does not issue warning if there is no transaction in progress. I faced into this problem when call to stored function which make use of configurations. and missed that this function has no effect because there is no transaction in progress -- Best regards, Eugen Konkov
Re: BUG #15646: Inconsistent behavior for current_setting/set_config
On 2/20/19 12:11 PM, Tom Lane wrote: > Joe Conway writes: >> On 2/20/19 11:10 AM, PG Bug reporting form wrote: >>> But current behavior returns empty string instead of NULL (the initial >>> value) after transaction is rolled back. When I restart session, NULL is >>> returned again as it is expected. > >> This has been discussed before and dismissed: >> https://www.postgresql.org/message-id/flat/56842412.505%40joeconway.com >> Personally I agree it is a bug, but I am not sure you will get much >> support for that position. > > The fact that we allow undeclared user-defined GUCs at all is a bug IMO. > We need to find a way to replace that behavior with something whereby > the name and type of a parameter are declared up-front before you can > set it. (moving to hackers) Perhaps we could do something like: 1. If the user-defined GUC is defined in postgresql.conf, et al, same behavior as now 2. Backward compatibility concerns would be an issue, so create another new GUC declare_custom_settings which initially defaults to false. 3. If declare_custom_settings is true, and the user-defined GUC is not defined in postgresql.conf, then in order to create it dynamically via SET or similar methods, you must do something like: CREATE SETTING name TYPE guctype [LIST]; SET name TO value; Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development signature.asc Description: OpenPGP digital signature
