Greg Smith wrote:
On Thu, 25 Sep 2008, Simon Riggs wrote:
So it would be useful to have a column that meant if I run the RESET
command it would return me to this value.
Patch v3 attached that exposes boot_val and reset_val. The docs for the
latter link to the RESET command page for
On Oct 5, 2008, at 8:50 PM, Greg Smith wrote:
Patch v3 attached that exposes boot_val and reset_val. The docs
for the latter link to the RESET command page for details.
nitpickIs it really that important that we save 2 characters on
each field name?/nitpick
--
Decibel!, aka Jim C. Nasby,
On Thu, 25 Sep 2008, Simon Riggs wrote:
So it would be useful to have a column that meant if I run the RESET
command it would return me to this value.
Patch v3 attached that exposes boot_val and reset_val. The docs for the
latter link to the RESET command page for details.
Sample, with
On Tue, 2008-09-16 at 00:10 -0400, Greg Smith wrote:
Attached is an updated and separate version of my patch exposing the
internal GUC boot_val as default_val, which failed to attach itself to the
already committed changes to the pg_settings view.
Brief reminder of what it does:
Simon Riggs [EMAIL PROTECTED] writes:
We have an RESET command which returns parameter to its default
setting. But what this means is return it to the value set in current
the postgresql.conf, if overriden therein from its default value. So it
would be useful to have a column that meant if I
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
We have an RESET command which returns parameter to its default
setting. But what this means is return it to the value set in current
the postgresql.conf, if overriden therein from its default value. So it
would be useful to have a column
On Thu, 2008-09-25 at 14:42 +0200, Magnus Hagander wrote:
If both are interesting to different audiences, perhaps we should be
exposing both as separate columns?
That seems best. It will make things much clearer.
Having
one column named reset_val and one named boot_val should work, no?
Simon Riggs wrote:
On Thu, 2008-09-25 at 14:42 +0200, Magnus Hagander wrote:
Having
one column named reset_val and one named boot_val should work, no?
Yes, those names seem very appropriate to me.
Finding the reset_val isn't that tough, IIRC the way the guc assignment
works with its doit
Magnus Hagander [EMAIL PROTECTED] writes:
It sounds like you are making the case for what I write above? Having
one column named reset_val and one named boot_val should work, no?
Well, that's what I've been saying right along, but the previous
discussion was all about what to call the columns
On Thu, 2008-09-25 at 14:52 +0200, Magnus Hagander wrote:
Simon Riggs wrote:
On Thu, 2008-09-25 at 14:42 +0200, Magnus Hagander wrote:
Having
one column named reset_val and one named boot_val should work, no?
Yes, those names seem very appropriate to me.
Finding the reset_val
On Thu, 2008-09-25 at 09:15 -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
It sounds like you are making the case for what I write above? Having
one column named reset_val and one named boot_val should work, no?
Well, that's what I've been saying right along, but the
On Thu, 25 Sep 2008, Simon Riggs wrote:
I would suggest we either alter pg_settings so that we display value
*only* when source=default (set NULL otherwise) or we do some extra work
to derive what the setting would be if we ran RESET. The latter would be
preferred approach.
Since getting the
12 matches
Mail list logo
