Mark Woodward wrote:
Well, if you want PostgreSQL to act a specific way, then you are going
to
have to set up the defaults somehow, right?
Of course, which is why we could use a global table for most of it.
What if you wish to start the same database cluster with different settings?
Then c
>> Well, if you want PostgreSQL to act a specific way, then you are going
>> to
>> have to set up the defaults somehow, right?
>
> Of course, which is why we could use a global table for most of it.
What if you wish to start the same database cluster with different settings?
>
>>
>> Which is clea
Josh Berkus wrote:
Josh,
My actual point was that we could put a lot of the options in a global
table that could be adjusted versus having the flat file.
You were aware of the virtual view pg_settings, right?
Yes and show all.
I've considered before adjusting pg_settings so that it wou
Josh Berkus writes:
> I've considered before adjusting pg_settings so that it would take
> UPDATEs and convert them to SET statements.
Uh, it's always done that. The issue here would be making it do
something with more persistent effect than a SET.
regards, tom lane
---
On 2005-08-08, Josh Berkus wrote:
> I've considered before adjusting pg_settings so that it would take UPDATEs
> and convert them to SET statements. However, I'm not really sure what the
> benefit of this would be.
It's done that (via rules) since at least as far back as 7.4, no?
(Though it s
Josh,
> > My actual point was that we could put a lot of the options in a global
> > table that could be adjusted versus having the flat file.
You were aware of the virtual view pg_settings, right?
I've considered before adjusting pg_settings so that it would take UPDATEs and
convert them to SE
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> My actual point was that we could put a lot of the options in a global
> table that could be adjusted versus having the flat file.
[ shrug... ] Then we would have two incompatible mechanisms instead of one.
(We can't eliminate the flat file complet
Well, if you want PostgreSQL to act a specific way, then you are going to
have to set up the defaults somehow, right?
Of course, which is why we could use a global table for most of it.
Which is cleaner? Using a configuration file which is going to be there
anyway, or trying to rig-up some so
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
As I have been laboring over the documentation of the postgresql.conf
file for 8.1dev it seems that it may be useful to rip out most of the
options in this file?
What? The contents of postgresql.conf *are* documentation.
Yes t
> Hello,
>
> As I have been laboring over the documentation of the postgresql.conf
> file for 8.1dev it seems that it may be useful to rip out most of the
> options in this file?
>
> Considering many of the options can already be altered using SET why
> not make it the default for many of them?
>
>
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> As I have been laboring over the documentation of the postgresql.conf
> file for 8.1dev it seems that it may be useful to rip out most of the
> options in this file?
What? The contents of postgresql.conf *are* documentation.
Hello,
As I have been laboring over the documentation of the postgresql.conf
file for 8.1dev it seems that it may be useful to rip out most of the
options in this file?
Considering many of the options can already be altered using SET why
not make it the default for many of them?
Sincerely,
12 matches
Mail list logo
