On Sat, Feb 11, 2012 at 1:36 PM, Kevin Grittner
<Kevin.Grittner@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
