Re: Parsing errors in pg_hba.conf

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parsing errors in pg_hba.conf
Date: 2008-10-27 12:52:04
Message-ID: 4905B974.2060000@hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2008-10-27 12:52:45 Re: Parsing errors in pg_hba.conf
Previous Message Tom Lane 2008-10-27 12:42:19 Re: ERRORDATA_STACK_SIZE exceeded (server crash)