Re: [PATCH v9] GSSAPI encryption support

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH v9] GSSAPI encryption support
Дата
Msg-id 8265.1459458639@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCH v9] GSSAPI encryption support  (Robbie Harwood <rharwood@redhat.com>)
Ответы Re: [PATCH v9] GSSAPI encryption support  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
Robbie Harwood <rharwood@redhat.com> writes:
>>> +   {
>>> +       {"gss_encrypt", PGC_USERSET, CONN_AUTH_SECURITY,
>>> +        gettext_noop("Require encryption for all GSSAPI connections."),
>>> +        NULL,
>>> +        GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE
>>> +       },
>>> +       &gss_encrypt, false, check_gss_encrypt, assign_gss_encrypt, NULL
>>> +   },

>> Why is this marked NOT_IN_SAMPLE?

> Well, because it's not something that's supposed to be set in the file
> (and indeed, you can't set it there, if I understand
> GUC_DISALLOW_IN_FILE).  It's used only as a connection parameter, and I
> use its presence / absence for the client and server to negotiate GSSAPI
> encryption support.

If that's what it is, it seems fairly broken to have it connected up to a
GUC variable.  Especially one that's USERSET; some people will wonder why
frobbing it with SET does nothing, and others will bitch that they think
it should be superuser-only or some such.  I'd keep it localized to the
connection logic, myself.  There's already logic in ProcessStartupPacket
for connection options that aren't GUC variables, so I'd suggest adding
another case there instead of pretending this is a settable GUC variable.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: improving GROUP BY estimation
Следующее
От: Jesper Pedersen
Дата:
Сообщение: Re: Speed up Clog Access by increasing CLOG buffers