Greg Smith wrote:
> On Tue, 9 Sep 2008, Magnus Hagander wrote:
>
>>> (I dropped the "default" stuff for now, as it doesn't seem that a
>>> consensus has been reached on that topic.)
>>
>> This is one of the reasons I suggested keeping that one as a separate
>> patch in the first place. The other ma
On Tue, 9 Sep 2008, Magnus Hagander wrote:
(I dropped the "default" stuff for now, as it doesn't seem that a
consensus has been reached on that topic.)
This is one of the reasons I suggested keeping that one as a separate
patch in the first place. The other main reason being that once it gets
Alvaro Herrera wrote:
> Tom Lane wrote:
>> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>>> Tom Lane wrote:
>
>>> Hmm, I didn't recheck after Greg's patch, but in mine, it doesn't,
>>> because the location is saved as "reset location" and restored when the
>>> variable is reset. It worked fine in a
On Mon, 8 Sep 2008, Alvaro Herrera wrote:
(I dropped the "default" stuff for now, as it doesn't seem that a
consensus has been reached on that topic.)
I have multiple GUC-related projects that are all stalled waiting for that
capability to be added. The only thing there wasn't clear consensu
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> > Hmm, I didn't recheck after Greg's patch, but in mine, it doesn't,
> > because the location is saved as "reset location" and restored when the
> > variable is reset. It worked fine in all cases I tested.
>
> Hmm
On Thu, 4 Sep 2008, Kevin Grittner wrote:
Personally, I would take the "Min", "Default", and "Max" to mean what
Greg intends; it's the "Current" one that gives me pause.
That's the output of current_setting(name) which shows what it is right
now; no more, no less. See
http://www.postgresql.
>>> Greg Smith <[EMAIL PROTECTED]> wrote:
> name | Recommended | Current | Min | Default | Max
> -+-+-+---+-+-
> wal_buffers | 1024kB | 64kB| 32 kB | 64 kB | 2048 MB
Personally, I would take the "Min", "Default", and
On Wed, 3 Sep 2008, Tom Lane wrote:
Greg Smith <[EMAIL PROTECTED]> writes:
First question--how about if I changed that description to read:
"Default value used at server startup if the parameter is not explicitly
set"?
"... not otherwise set" would probably be an accurate phrasing.
(I'm th
Before I respond to Tom's comments, let me step back a second and add the
intro the deadline didn't leave me time for. There are two specific
things the bit I added to this GUC patch is aimed at:
1) Somebody has a postgresql.conf from a random source (saw it on the
Internet and pasted dubious
Greg Smith <[EMAIL PROTECTED]> writes:
> First question--how about if I changed that description to read:
> "Default value used at server startup if the parameter is not explicitly
> set"?
"... not otherwise set" would probably be an accurate phrasing.
(I'm thinking of corner cases like stuff ab
Joshua Drake <[EMAIL PROTECTED]> writes:
> I guess I would ask, "Who else would we be targeting this for?". DBAs
> seem to be the only logical choice.
Regular users look at pg_settings too, you know. Maybe *you* only
get questions from DBAs...
regards, tom lane
--
Sent
On Wed, 3 Sep 2008 16:04:12 -0400 (EDT)
Greg Smith <[EMAIL PROTECTED]> wrote:
> Section question: with those changes, would it then be reasonable to
> you to keep that column named "default" instead of giving it a less
> common name?
>
> > You are adopting a very narrow mindset, which seems to
On Wed, 3 Sep 2008, Tom Lane wrote:
"Default value if the parameter is not explicitly set"
If that statement were the truth, the whole truth, and nothing but the
truth, and if it didn't ignore the point about "explicitly set WHERE?",
I'd be fine with it.
First question--how about if I changed
Greg Smith <[EMAIL PROTECTED]> writes:
> On Tue, 2 Sep 2008, Tom Lane wrote:
>>> How about having two new columns "reset value" and "boot value"?
>>
>> Like it better than "default value" ...
> It's being a bit pedantic at the expense of the user, but I don't really
> care that much here. I exp
On Tue, 2 Sep 2008, Tom Lane wrote:
How about having two new columns "reset value" and "boot value"?
Like it better than "default value" ...
It's being a bit pedantic at the expense of the user, but I don't really
care that much here. I exposed the boot_val and described it in the
documen
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Greg just sent me this patch, augmenting the one I sent to add source
> > file and line to GUC vars; Greg's patch adds a column with the default
> > value of each var.
>
> I haven't tested, but doesn't this lose the source-location i
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I haven't tested, but doesn't this lose the source-location information
>> if a setting acquired from the config file is temporarily overridden via
>> SET (consider SET LOCAL, or a SET in a rolled-back xact)? It'll go to
>> NULL and n
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Greg just sent me this patch, augmenting the one I sent to add source
> file and line to GUC vars; Greg's patch adds a column with the default
> value of each var.
I haven't tested, but doesn't this lose the source-location information
if a setting acqu
Greg just sent me this patch, augmenting the one I sent to add source
file and line to GUC vars; Greg's patch adds a column with the default
value of each var.
I forward it to -hackers to have a public Message-Id to link to in the
Commitfest page.
--
Alvaro Herrera
Robert Treat wrote:
> On Thursday 28 August 2008 13:08:58 Alvaro Herrera wrote:
> > This should make life easier for tools trying to find the config file
> > each setting is from (and possibly edit it).
>
> If I have read this patch right, anything commented out (aka all of our
> default values)
On Thursday 28 August 2008 13:08:58 Alvaro Herrera wrote:
> Hi,
>
> Here's a patch to add source file and line numbers to GUC variables.
> Basically this makes pg_settings look like this:
>
> This should make life easier for tools trying to find the config file
> each setting is from (and possibly
Greg Smith wrote:
> This looks quite handy. Needs to have an update to the view-pg-settings
> section of the docs before it gets applied though.
>
> I'd also like to get the default boot_val for each parameter exposed,
> similarly to how the min and max are available. That should be easy to
> do
This looks quite handy. Needs to have an update to the view-pg-settings
section of the docs before it gets applied though.
I'd also like to get the default boot_val for each parameter exposed,
similarly to how the min and max are available. That should be easy to do
using your changes as a g
23 matches
Mail list logo
