Skip site navigation (1) Skip section navigation (2)

Re: setting per-database/role parameters checks them against wrong context

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: setting per-database/role parameters checks them against wrong context
Date: 2012-09-28 14:10:34
Message-ID: 22133.1348841434@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Peter Eisentraut <peter_e(at)gmx(dot)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


In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2012-09-28 14:35:55
Subject: Re: 64-bit API for large object
Previous:From: Marko KreenDate: 2012-09-28 14:08:41
Subject: Re: [9.1] 2 bugs with extensions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group