On Sat, Feb 11, 2012 at 1:36 PM, Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: > "Kevin Grittner" wrote: > Tom Lane wrote: > >>> I agree it's a bug that you can do what Kevin's example shows. >> >> I'll look at it and see if I can pull together a patch. > > Attached. > > Basically, if a GUC has a check function, this patch causes it to be > run on a RESET just like it is on a SET, to make sure that the > resulting value is valid to set within the context. Some messages > needed adjustment. While I was there, I made cod a little more > consistent among related GUCs. > > I also added a little to the regression tests to cover this.
This patch makes me a little nervous, because the existing behavior seems to have been coded for quite deliberately. Sadly, I don't see any comments explaining why the RESET case was excluded originally. On the other hand, I can't see what it would break, either. Have you gone through all the check hooks and verified that we're not violating any of their assumptions? I assume that you're thinking we'd only fix this in master? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
