Обсуждение: Re: BUG #15646: Inconsistent behavior for current_setting/set_config

Поиск
Список
Период
Сортировка

Re: BUG #15646: Inconsistent behavior for current_setting/set_config

От
Joe Conway
Дата:
On 2/20/19 12:11 PM, Tom Lane wrote:
> Joe Conway <mail@joeconway.com> 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.5000005%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


Вложения

Re: BUG #15646: Inconsistent behavior for current_setting/set_config

От
Eugen Konkov
Дата:
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

От
Eugen Konkov
Дата:
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
currenttransaction. 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

От
"David G. Johnston"
Дата:
On Tuesday, February 26, 2019, Eugen Konkov <kes-kes@yandex.ru> 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.