On Sun, Apr 3, 2011 at 1:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> IMO the real problem is essentially that GUC assign hooks have two
> functions, checking and canonicalization of the value-to-be-stored
> versus executing secondary actions when an assignment is made; and
> there's no way to get at just the first one.
Yes, I think that's right. A related point is that the API for assign
hooks is not consistent across all data types: string assign hooks can
return a replacement value, whereas everyone else can only succeed or
> It would probably take less than a day to flesh out this idea and make
> it happen, but it does seem like a rather large change for late alpha.
> If people don't want to do this now, I suggest that we just live with
> the problem for 9.1. It's purely cosmetic, and easy enough to work
> around (just don't uncomment the default value).
I think it's a pretty ugly wart, so I'm inclined to say go ahead and
fix it. I'm not sure what alpha is for if it's not cleaning up the
detritus of all the stuff we've committed in the last 9 months. AIUI,
what we're trying to avoid is committing new stuff that may require
additional cleanup, not cleaning up the stuff we already did commit.
Once we get to beta I'll be less enthusiastic about making changes
like this, but I think most of the testing that will get done is still
in front of us.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2011-04-03 23:16:32|
|Subject: Re: GUC assign hooks (was Re: wal_buffers = -1 and SIGHUP) |
|Previous:||From: Heikki Linnakangas||Date: 2011-04-03 18:05:59|
|Subject: Re: FDW state from plan time|