From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Custom variables and flags, again |
Date: | 2008-11-17 02:07:43 |
Message-ID: | 15925.1226887663@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Perhaps more to the point, guc_tables.h is a file that we don't even
>> want the majority of the backend including. Why would we think it's
>> a good idea to make that part of the public API to external modules?
> Hmmm... do we need to move config_group enumerations to guc.h from
> guc_tables.h ? Or, we cannot expose the group field and always use
> CUSTOM_OPTIONS for custom variables.
My inclination is not to expose that, and just use CUSTOM_OPTIONS
always. As was noted earlier, the config_group enumeration seems
really ad-hoc and subject to change, so keeping external modules away
from it seems the best thing to me.
We do need to move some of the GUC flags #defines (not sure about all
of them...) into guc.h, if we want to take the position that external
modules shouldn't import guc_tables.h.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2008-11-17 02:46:51 | Re: Custom variables and flags, again |
Previous Message | ITAGAKI Takahiro | 2008-11-17 02:03:42 | Re: Custom variables and flags, again |