On Mon, Apr 4, 2011 at 4:57 PM, Tom Lane wrote:
> Robert Haas writes:
>> OK. Please comment the crap out of whatever you do, or maybe even add
>> a README. This stuff is just a bit arcane, and guideposts help a lot.
>
> We already have a README for that ;-). PFA, a patch to
> src/backend/utils
Robert Haas writes:
> OK. Please comment the crap out of whatever you do, or maybe even add
> a README. This stuff is just a bit arcane, and guideposts help a lot.
We already have a README for that ;-). PFA, a patch to
src/backend/utils/misc/README describing the proposed revised API.
If nobo
On Mon, Apr 4, 2011 at 3:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 4, 2011 at 2:58 PM, Tom Lane wrote:
>>> Another variant would be to allow the check_hook to pass back a separate
>>> "void *" value that could be passed on to the assign_hook, containing
>>> any necessary derive
Robert Haas writes:
> On Mon, Apr 4, 2011 at 2:58 PM, Tom Lane wrote:
>> Another variant would be to allow the check_hook to pass back a separate
>> "void *" value that could be passed on to the assign_hook, containing
>> any necessary derived data. This is logically a bit cleaner, and would
>>
On Mon, Apr 4, 2011 at 2:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 4, 2011 at 2:41 PM, Tom Lane wrote:
>>> Given these rules, a check_hook and assign_hook could cooperate to store
>>> additional data in what guc.c thinks is just a pointer to a string
>>> value, ie, there can be
Robert Haas writes:
> On Mon, Apr 4, 2011 at 2:41 PM, Tom Lane wrote:
>> Given these rules, a check_hook and assign_hook could cooperate to store
>> additional data in what guc.c thinks is just a pointer to a string
>> value, ie, there can be more data after the terminating \0. The
>> assign_hoo
On Mon, Apr 4, 2011 at 2:41 PM, Tom Lane wrote:
> I 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 j
I 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. So we cannot canonicalize
> the val
Robert Haas wrote:
> On Sun, Apr 3, 2011 at 1:26 PM, Tom Lane wrote:
>> 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.
> what we're trying to avoid is committing new stuff that may require
> a
Robert Haas writes:
> On Sun, Apr 3, 2011 at 1:26 PM, Tom Lane 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
On Sun, Apr 3, 2011 at 1:26 PM, Tom Lane 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 o
I wrote:
> Robert Haas writes:
>> I had intended to commit Greg's patch with a show hook and an assign
>> hook and the calculated value stored separately from the GUC variable,
>> which I believe would avoid this is a problem, but Tom thought this
>> way was better. Unfortunately, my knowledge of
12 matches
Mail list logo
