On 13/12/13 04:11, Greg Stark wrote:
On 12 Dec 2013 04:20, "Álvaro Hernández Tortosa" mailto:a...@nosys.es>> wrote:
> Thanks, Greg. I've been going through those threads, they are
quite interesting. I didn't find an answer, though, about my question:
why parsing the postgresql.conf (
On 12 Dec 2013 04:20, "Álvaro Hernández Tortosa" wrote:
> Thanks, Greg. I've been going through those threads, they are
quite interesting. I didn't find an answer, though, about my question: why
parsing the postgresql.conf (and for instance preserving the comments while
writing it back) i
On 09/12/13 18:00, Robert Haas wrote:
On Fri, Dec 6, 2013 at 10:28 PM, Álvaro Hernández Tortosa wrote:
I think both could be used a lot, editing directly a rich configuration
file or using a GUI tool. I'm trying to suggest supporting both.
I don't really understand how changing the fil
On 09/12/13 18:26, Greg Stark wrote:
On Sat, Dec 7, 2013 at 3:28 AM, Álvaro Hernández Tortosa wrote:
"Right now, writing such a tool in a generic way gets so bogged down
just in parsing/manipulating the postgresql.conf file that it's hard to
focus on actually doing the tuning part."
That wa
On Sat, Dec 7, 2013 at 3:28 AM, Álvaro Hernández Tortosa wrote:
>>> "Right now, writing such a tool in a generic way gets so bogged down
>>> just in parsing/manipulating the postgresql.conf file that it's hard to
>>> focus on actually doing the tuning part."
>>
>> That was in 2008. I don't think
On Fri, Dec 6, 2013 at 10:28 PM, Álvaro Hernández Tortosa wrote:
> I think both could be used a lot, editing directly a rich configuration
> file or using a GUI tool. I'm trying to suggest supporting both.
I don't really understand how changing the file format fixes anything.
You could make
On 06/12/2013 22:59, Peter Eisentraut wrote:
On 12/6/13, 12:29 PM, Álvaro Hernández Tortosa wrote:
What I've been trying to do is summarize what has already been
discussed here and propose a solution. You say that "you can already do
those thisngs", but that's not what I have read here. Gr
On 06/12/2013 19:11, David Johnston wrote:
Álvaro Hernández Tortosa wrote
Note that you are not required to maintain your configuration data in a
postgresql.conf-formatted file. You can keep it anywhere you like, GUI
around in it, and convert it back to the required format. Most of the
On 12/6/13, 12:29 PM, Álvaro Hernández Tortosa wrote:
> What I've been trying to do is summarize what has already been
> discussed here and propose a solution. You say that "you can already do
> those thisngs", but that's not what I have read here. Greg Smith (cc'ed
> as I'm quoting you) was ex
Álvaro Hernández Tortosa wrote
>> Note that you are not required to maintain your configuration data in a
>> postgresql.conf-formatted file. You can keep it anywhere you like, GUI
>> around in it, and convert it back to the required format. Most of the
>
> I think it is not a very good i
On 06/12/13 04:47, Peter Eisentraut wrote:
On Thu, 2013-12-05 at 00:51 +0100, Álvaro Hernández Tortosa wrote:
The tradeoff seems quite positive to me. I see no strong
reasons why
not do it... am I missing something?
I don't buy your argument. You say, if we make this change, tho
On Thu, 2013-12-05 at 00:51 +0100, Álvaro Hernández Tortosa wrote:
> In return for this extra information, we:
>
> - Provide users with more help (information) to help them configure
> postgres (which is no easy task, specially for newcomers).
>
> - Help and encourage app developers to create bo
On 12/4/13, 2:02 PM, Álvaro Hernández Tortosa wrote:
> So optional fields are either purely optional (i.e., only for tools
> that want to use them; everyone else may ignore, but preserve, them) and
> some other are just NULLABLEs, depending on the parameter).
But my point stands: If it's optio
On 04/12/13 20:44, Peter Eisentraut wrote:
On 12/4/13, 2:02 PM, Álvaro Hernández Tortosa wrote:
So optional fields are either purely optional (i.e., only for tools
that want to use them; everyone else may ignore, but preserve, them) and
some other are just NULLABLEs, depending on the para
On 04/12/13 19:49, Peter Eisentraut wrote:
On 12/4/13, 11:22 AM, Álvaro Hernández Tortosa wrote:
Would it be well-received a new file format that keeps it simple for
both hand editing and generation of the configuration, and at the same
time offers the features I have mentioned?
I don't see
On 12/4/13, 11:22 AM, Álvaro Hernández Tortosa wrote:
> Would it be well-received a new file format that keeps it simple for
> both hand editing and generation of the configuration, and at the same
> time offers the features I have mentioned?
I don't see how that would work exactly: You want to ad
On 04/12/13 16:51, Peter Eisentraut wrote:
On 12/4/13, 1:42 AM, Álvaro Hernández Tortosa wrote:
IMHO, a data structure like the above would be completely
self-contained and allow any autoconfiguring tool or GUI tool to be
easily created, if the syntax is programmable. It would certainly m
On 12/4/13, 1:42 AM, Álvaro Hernández Tortosa wrote:
> IMHO, a data structure like the above would be completely
> self-contained and allow any autoconfiguring tool or GUI tool to be
> easily created, if the syntax is programmable. It would certainly make
> the config file more verbose, but at
Hi Peter, Dimitri, thank you for your comments.
On 03/12/13 22:27, Dimitri Fontaine wrote:
Peter Eisentraut writes:
On 12/1/13, 2:24 PM, Álvaro Hernández Tortosa wrote:
IMHO, defining a new syntax for the postgreql.conf file format,
that is suitable for writing and parsing,
Peter Eisentraut writes:
> On 12/1/13, 2:24 PM, Álvaro Hernández Tortosa wrote:
>> IMHO, defining a new syntax for the postgreql.conf file format,
>> that is suitable for writing and parsing, or using an already existing,
>> well-known, programmatic syntax, could offer a solution for all t
On 12/1/13, 2:24 PM, Álvaro Hernández Tortosa wrote:
> IMHO, defining a new syntax for the postgreql.conf file format,
> that is suitable for writing and parsing, or using an already existing,
> well-known, programmatic syntax, could offer a solution for all the
> problems/limitations above
Hi there!
I've been reading several threads debating about the format of
postgresql.conf and improvements to it (like "Overhauling GUCS" [1] or
"Proposal for Allow postgresql.conf values to be changed via SQL" [2]).
Trying to summarize that in my own opinion, I think that the cur
22 matches
Mail list logo
