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
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 value
On Mon, Apr 4, 2011 at 2:41 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 4, 2011 at 2:41 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Apr 4, 2011 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 4, 2011 at 2:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Given these rules, a check_hook and assign_hook could cooperate to store
additional data in what guc.c thinks is just
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 4, 2011 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Apr 4, 2011 at 3:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 4, 2011 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Another variant would be to allow the check_hook to pass back a separate
void * value that could be passed on to the
Robert Haas robertmh...@gmail.com 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
On Mon, Apr 4, 2011 at 4:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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 ;-).
I wrote:
Robert Haas robertmh...@gmail.com 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
On Sun, Apr 3, 2011 at 1:26 PM, Tom Lane t...@sss.pgh.pa.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
Robert Haas robertmh...@gmail.com writes:
On Sun, Apr 3, 2011 at 1:26 PM, Tom Lane t...@sss.pgh.pa.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
Robert Haas robertmh...@gmail.com writes:
On Thu, Mar 31, 2011 at 8:38 AM, Bernd Helmle maili...@oopsware.de wrote:
This might be nitpicking (or i'm currently missing something), but i
recognized that setting wal_buffers = -1 always triggers the following on
reload, even if nothing to
This might be nitpicking (or i'm currently missing something), but i recognized
that setting wal_buffers = -1 always triggers the following on reload, even if
nothing to wal_buffers had changed:
$ pg_ctl reload
LOG: received SIGHUP, reloading configuration files
LOG: parameter wal_buffers
On Thu, Mar 31, 2011 at 8:38 AM, Bernd Helmle maili...@oopsware.de wrote:
This might be nitpicking (or i'm currently missing something), but i
recognized that setting wal_buffers = -1 always triggers the following on
reload, even if nothing to wal_buffers had changed:
$ pg_ctl reload
LOG:
15 matches
Mail list logo
