On 2/20/19 12:11 PM, Tom Lane wrote: > Joe Conway <m...@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
signature.asc
Description: OpenPGP digital signature