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.
Is it really that important that we save 2 characters on
each field name?
--
Decibel!, aka Jim C. Nasby, Database Archit
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
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 d
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 v
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
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 t
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 column
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
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?
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
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 mea
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:
>
>
12 matches
Mail list logo
