Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
