Re: RFC: programmable file format for postgresql.conf - Mailing list pgsql-hackers

From Álvaro Hernández Tortosa
Subject Re: RFC: programmable file format for postgresql.conf
Date
Msg-id 529F7C3F.5040900@nosys.es
Whole thread Raw
In response to Re: RFC: programmable file format for postgresql.conf  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: RFC: programmable file format for postgresql.conf
List pgsql-hackers

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 how that would work exactly: You want to add various kinds
> of complex metadata to the configuration file, but make that metadata
> optional at the same time.  The immediate result will be that almost no
> one will supply the optional metadata, and no tools will be able to rely
> on their presence.
>
I wouldn't say the metadata is "complex". Looks quite familiar to that 
of pg_settings (besides that, it was just a brainstorming, not a formal 
proposal).
The optional fields are basically NULLABLE attributes in pg_settings. 
That is, they only make sense depending on other values (in this case, 
the parameter name). All of the attributes that are required for tools 
to work are marked as non optional.
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).
In any case, my idea is just to open up the question and search for the 
best possible set of data to be represented, and then, the best possible 
syntax / file format for it.

aht

-- 
Álvaro Hernández Tortosa


-----------
NOSYS
Networked Open SYStems



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: RFC: programmable file format for postgresql.conf
Next
From: Josh Berkus
Date:
Subject: Re: Why we are going to have to go DirectIO