On Fri, Sep 28, 2012 at 7:10 AM, Tom Lane <[email protected]> wrote: > Peter Eisentraut <[email protected]> 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.
The check_temp_buffers() problem seems like a regression and blocks us from upgrading to 9.2. The use case are functions that set temp_buffers and occasionally are called in a series from a parent session. The work around is... a lot of work. I'd appreciate it if we could fix the temp_buffers issue, and I support getting rid of context-sensitive restrictions. :) -selena -- http://chesnok.com -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
