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
|
Список | 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 по дате отправления: