Robert Haas writes:
> I kind of dislike SET PERMANENT as a command name, partly because I
> think it sounds more certain than it really is, and partly because
> it's asymmetric with the other, similar GUC-setting commands, which
> are:
> ALTER ROLE name [ IN DATABASE database_name ] SET
> configu
Andrew Dunstan writes:
> If the file is completely machine-maintained, including the comments, it
> seems eminently doable. It's only if the file gets mangled by humans
> that there's a problem.
Yeah. We could have comments that were injected by some sort of COMMENT
ON command, stored in the f
On 10/14/2010 01:10 PM, Robert Haas wrote:
On Thu, Oct 14, 2010 at 12:40 PM, Josh Berkus wrote:
Sure. I just lose comments. I'll live with that.
Actually, as part of this scheme, it would be nice if pg_settings had a
"comment" column, which would be optionally set with SET PERMANENT. Not
re
On Thu, Oct 14, 2010 at 9:50 AM, Tom Lane wrote:
> The fact is that you cannot know the active value anyway without
> checking, because what you did with SET PERMANENT might be overridden
> in various session-local ways. The proposal for hand-edited versus
> machine-edited files just adds one mor
On Thu, Oct 14, 2010 at 12:40 PM, Josh Berkus wrote:
>
>> Sure. I just lose comments. I'll live with that.
>
> Actually, as part of this scheme, it would be nice if pg_settings had a
> "comment" column, which would be optionally set with SET PERMANENT. Not
> required, but nice to have.
>
> If we
Sure. I just lose comments. I'll live with that.
Actually, as part of this scheme, it would be nice if pg_settings had a
"comment" column, which would be optionally set with SET PERMANENT. Not
required, but nice to have.
If we had that, I suspect that a lot fewer people would want a
hand
Tom Lane writes:
> [ shrug... ] So don't use the option of hand-editing postgresql.conf.
> You're not being forced to do that, and on the other side of the coin,
> you shouldn't think that you get to force people who'd rather hand-edit
> to change their habits.
Sure. I just lose comments. I'll l
Dimitri Fontaine writes:
> I understand that. I just think there are already too many sources for
> GUCs and would welcome that there's a single possible source file with a
> complete remote editing feature.
[ shrug... ] So don't use the option of hand-editing postgresql.conf.
You're not being f
Tom Lane writes:
>> SELECT pg_load_conf('path/to/filename.conf', permament => true);
>
> That seems like a pretty bizarre idea. The settings wouldn't be
> persistent would they? Or are you proposing this as a substitute
> way of providing input for SET PERMANENT? If so what's the value?
Yeah
Tom Lane writes:
> Um, other than "show work_mem" or "select from pg_settings"?
>
> The fact is that you cannot know the active value anyway without
> checking, because what you did with SET PERMANENT might be overridden
> in various session-local ways. The proposal for hand-edited versus
> machi
Dimitri Fontaine writes:
> I wonder if providing a system function to load some configuration
> option from a file, using the current parser, would do it:
> SELECT pg_load_conf('path/to/filename.conf', permament => true);
That seems like a pretty bizarre idea. The settings wouldn't be
persist
Dimitri Fontaine writes:
> Allow me to insist on this some more, because there's something
> important going on here. The other proposal (.auto) have a major failure
> mode that I don't think is acceptable.
> SET PERMANENT work_mem TO '8 MB';
> select pg_reload_conf();
> There's simply no wa
Dimitri Fontaine writes:
> Ok, now, some people want to still be able to edit the files by hand
I wonder if providing a system function to load some configuration
option from a file, using the current parser, would do it:
SELECT pg_load_conf('path/to/filename.conf', permament => true);
Of cou
Dimitri Fontaine writes:
> cat postgresql.conf.d/work_mem
> 16MB
> This database needs at least such a value.
> Note it's overridden in some ROLEs setup.
>
>
> With such a format (name is filename, value is first line content's,
> rest is comments), it's easy to preserve comments and have them mac
On Wed, Oct 13, 2010 at 12:56:15PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > But creating a separate file doesn't fix that problem. It just moves
> > it around. If people will expect comments in postgresql.conf to get
> > preserved, then why won't they also expect comments in
> > postgre
> IIRC the proposal was that postgresql.conf (the people-editable file)
> would have "include postgresql.auto" in it. You could put that at
> the top, bottom, or even middle to control how the priority works.
> So it's user-configurable. I think the factory default ought to
> be to have it at th
Robert Haas writes:
> But creating a separate file doesn't fix that problem. It just moves
> it around. If people will expect comments in postgresql.conf to get
> preserved, then why won't they also expect comments in
> postgresql.conf.auto to get preserved?
Because postgresql.conf.auto will ha
On Wed, Oct 13, 2010 at 10:25 AM, Tom Lane wrote:
> Robert Haas writes:
>> You're not alone on this at all: I agree 100%. I don't like your
>> proposed syntax, but I completely agree with your concern. I don't
>> see what's wrong with having the initial contents of postgresql.conf
>> look like
Tom Lane writes:
> I'm not sure if anybody is particularly against the initial contents
> looking like that. The big problem, which both you and Dimitri are
> conveniently ignoring, is that if people are allowed to hand-edit
> the file they are going to introduce comments that no mechanical
> par
On Oct 13, 2010, at 10:24 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> +1. Preserving the comments when you change the value could make the
>> comments totally bogus. Separating machine-generated values into a
>> separate file makes plenty of sense to me.
>
>> Which one wins, though? I can
Andrew Dunstan writes:
> +1. Preserving the comments when you change the value could make the
> comments totally bogus. Separating machine-generated values into a
> separate file makes plenty of sense to me.
> Which one wins, though? I can see cases being made for both.
IIRC the proposal was t
On 10/13/2010 10:25 AM, Tom Lane wrote:
Robert Haas writes:
You're not alone on this at all: I agree 100%. I don't like your
proposed syntax, but I completely agree with your concern. I don't
see what's wrong with having the initial contents of postgresql.conf
look like this (these are the
Robert Haas writes:
> You're not alone on this at all: I agree 100%. I don't like your
> proposed syntax, but I completely agree with your concern. I don't
> see what's wrong with having the initial contents of postgresql.conf
> look like this (these are the settings that are uncommented by defa
On Wed, Oct 13, 2010 at 3:41 AM, Dimitri Fontaine
wrote:
> Tom Lane writes:
>> I agree with Josh's proposal: keep mechanically-generated settings in a
>> separate file, and don't even pretend to allow comments to be kept there.
>
> And then, when you SET PERMANENT knob TO value (or whatever the s
Tom Lane writes:
> I agree with Josh's proposal: keep mechanically-generated settings in a
> separate file, and don't even pretend to allow comments to be kept there.
And then, when you SET PERMANENT knob TO value (or whatever the syntax
is), you never know what value is selected at next startup
Richard Broersma wrote:
On Tue, Oct 12, 2010 at 3:54 PM, Josh Berkus wrote:
Oh. Now that's an interesting perspective ... you're suggesting that we
take the comments and apply them as COMMENTS on the specific pg_settings?
On a side note regarding comments, I'd like to make a request for a
mo
Josh Berkus wrote first:
Postgres has "COMMENT ON ..." SQL for various database objects and I
assumed that said comments would be stored in the system catalog.
Oh. Now that's an interesting perspective ... you're suggesting that we
take the comments and apply them as COMMENTS on the specific p
Josh Berkus writes:
>> Postgres has "COMMENT ON ..." SQL for various database objects and I
>> assumed that said comments would be stored in the system catalog.
> Oh. Now that's an interesting perspective ... you're suggesting that we
> take the comments and apply them as COMMENTS on the specifi
On Tue, Oct 12, 2010 at 3:54 PM, Josh Berkus wrote:
> Oh. Now that's an interesting perspective ... you're suggesting that we
> take the comments and apply them as COMMENTS on the specific pg_settings?
On a side note regarding comments, I'd like to make a request for a
more comprehensive commen
> Postgres has "COMMENT ON ..." SQL for various database objects and I
> assumed that said comments would be stored in the system catalog.
Oh. Now that's an interesting perspective ... you're suggesting that we
take the comments and apply them as COMMENTS on the specific pg_settings?
That would
Josh Berkus wrote:
The fact that Postgres already
explicitly supports comment metadata in its system catalog means it must
already know something about this.
We support what?
Postgres has "COMMENT ON ..." SQL for various database objects and I assumed
that said comments would be stored in t
Darren, All,
> All you would need is for the file parser to retain the
> comments as metadata, include them in the relations that the SQL
> commands see where the latter can also edit them as data, and then write
> out the updated file with comments.
"All you need to do" in order to trisect and a
Darren Duncan wrote:
> why is it not possible to retain the single existing postgres.conf
> file format (human writable) *and* have it machine/SQL-editable
> *and* maintain the comments?
My recollection of the previous discussion wasn't that there was no
way to do it, but rather that each pers
Dimitri Fontaine wrote:
Andrew Dunstan writes:
On 10/12/2010 05:02 PM, Dimitri Fontaine wrote:
So, what you do is have a file per GUC, file name is the GUC name, first
line contains *ONLY* current value, the rest of the file is comments.
You're joking, right?
No. I just want both comments
Andrew Dunstan writes:
> On 10/12/2010 05:02 PM, Dimitri Fontaine wrote:
>> So, what you do is have a file per GUC, file name is the GUC name, first
>> line contains *ONLY* current value, the rest of the file is comments.
>
> You're joking, right?
No. I just want both comments and SQL commands.
On 10/12/2010 05:02 PM, Dimitri Fontaine wrote:
So, what you do is have a file per GUC, file name is the GUC name, first
line contains *ONLY* current value, the rest of the file is comments.
You're joking, right?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
36 matches
Mail list logo
