Re: Parsing errors in pg_hba.conf

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Parsing errors in pg_hba.conf
Дата
Msg-id 4905B974.2060000@hagander.net
обсуждение исходный текст
Ответ на Re: Parsing errors in pg_hba.conf  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Parsing errors in pg_hba.conf  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> In a number of places in pg_hba.conf, we don't actually log what goes
>> wrong - instead we just goto a label that will log "invalid token \"%s\"".
> 
>> Is there any special reason for this, other than the fact that it was
>> the easy way out? I think it would be reasonable to for example log
>> "hostssl not supported on this platform" instead of that, when USE_SSL
>> is not defined, etc.
> 
> It would be seriously messy to try to make the parse-error code know
> about things like that.  Better would be to keep the GUC variable in
> existence always and have an assign hook to throw the error.

Um, no, it wouldn't :-) At least that's my impression. We're only
talking a bout the pg_hba code. Today it basically looks lilke:       if (token[4] == 's')    /* "hostssl" */       {
#ifdef USE_SSL           parsedline->conntype = ctHostSSL;
#else           /* We don't accept this keyword at all if no SSL support */           goto hba_syntax;
#endif       }

We could just replace the "goto" there with an ereport() and then a
"return false", because that's what hba_syntax does.

We have a total of 8 places that we do this instead of logging a
"complete error message".

(it used to be a bit more messy than this, which could also be the
reason why we didn't do it)

//Magnus


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ERRORDATA_STACK_SIZE exceeded (server crash)
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Parsing errors in pg_hba.conf