| От | Tom Lane |
|---|---|
| Тема | Re: GUC vs variable.c (was Patches applied...) |
| Дата | |
| Msg-id | 28958.1019433227@sss.pgh.pa.us обсуждение |
| Ответ на | Re: GUC vs variable.c (was Patches applied...) (Thomas Lockhart <thomas@fourpalms.org>) |
| Список | pgsql-hackers |
Thomas Lockhart <thomas@fourpalms.org> writes:
> Hmm. In looking at SET, why couldn't we develop this as an extendable
> capability a la pg_proc?
Well, my thoughts were along the line of providing specialized parsing
subroutines tied to specific GUC variables. There already are
parse_hook and assign_hook concepts in GUC, but possibly they need a
little more generalization to cover what these variables need to do.
If you're suggesting setting up an actual database table, I'm not
sure I see the point. Any system parameter is going to have to be
tied to backend code that knows what to do with the parameter, so
it's not like you can expect to do anything useful purely by adding
table entries. The C-code tables existing inside guc.c seem like
enough flexibility to me.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера