Re: RFC: programmable file format for postgresql.conf

Поиск
Список
Период
Сортировка
От Álvaro Hernández Tortosa
Тема Re: RFC: programmable file format for postgresql.conf
Дата
Msg-id 529F7C3F.5040900@nosys.es
обсуждение исходный текст
Ответ на Re: RFC: programmable file format for postgresql.conf  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: RFC: programmable file format for postgresql.conf
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: RFC: programmable file format for postgresql.conf
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Why we are going to have to go DirectIO