Peter Eisentraut <pete...@gmx.net> writes: > Example: > create temporary table foo (a int); > insert into foo values (1); > alter role peter set temp_buffers = 120; > ERROR: 22023: invalid value for parameter "temp_buffers": 120 > DETAIL: "temp_buffers" cannot be changed after any temporary tables > have been accessed in the session.
> Another example: > set log_statement_stats = on; > alter role peter set log_parser_stats = on; > ERROR: 22023: invalid value for parameter "log_parser_stats": 1 > DETAIL: Cannot enable parameter when "log_statement_stats" is true. > Another example is that in <=9.1, ALTER DATABASE ... SET search_path > would check the existence of the schema in the current database, but > that was done away with in 9.2. > The first example could probably be fixed if check_temp_buffers() paid > attention to the GucSource, but in the second case and in general there > doesn't seem to be a way to distinguish "assigning per-database setting" > and "enacting per-database setting" as a source. > Ideas? Perhaps instead of trying to solve the problem as stated, it would be more useful to put the effort into getting rid of context-sensitive restrictions on GUC settings. Neither of the examples above seem particularly essential - they are just protecting incomplete implementations. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers