Re: [PATCH] Store Extension Options
От | Fabrizio Mello |
---|---|
Тема | Re: [PATCH] Store Extension Options |
Дата | |
Msg-id | 3C2DD685-DDCF-4F5F-899A-11533FF7062A@gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Store Extension Options (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [PATCH] Store Extension Options
|
Список | pgsql-hackers |
Enviado via iPhone > Em 02/01/2014, às 22:16, Robert Haas <robertmhaas@gmail.com> escreveu: > >> On Thu, Jan 2, 2014 at 4:19 AM, Andres Freund <andres@2ndquadrant.com> wrote: >> On 2013-12-31 13:37:59 +0100, Pavel Stehule wrote: >>>> We use the namespace "ext" to the internal code >>>> (src/backend/access/common/reloptions.c) skip some validations and store >>>> the custom GUC. >>>> >>>> Do you think we don't need to use the "ext" namespace? >>> >>> yes - there be same mechanism as we use for GUC >> >> There is no existing mechanism to handle conflicts for GUCs. The >> difference is that for GUCs nearly no "namespaced" GUCs exist (plperl, >> plpgsql have some), but postgres defines at least autovacuum. and >> toast. namespaces for relation options. > > I continue to think that the case for having this feature at all has > not been well-made. > We can use this feature to store any custom GUC for relations, attributes and functions also. Some use cases: * extension options * config for external apps (frameworks, third part software) Comments? Regards, Fabrízio Mello
В списке pgsql-hackers по дате отправления: