Noah Misch <n...@leadboat.com> writes:
> Setting aside whether we should offer a better diagnostic when a user points
> "include" at a directory, the yy_fatal_error hack that made sense for scan.l
> doesn't cut it for guc-file.l. Like other guc-file.l errors, we need to
> choose the elevel based on which process is running the code. ERROR is never
> the right choice. We should instead stash the message, longjmp out of the
> flex parser, and proceed to handle the error mostly like a regular syntax
> error. See attached small patch.
Well, if you're going to criticize the original method as being hackish,
you really need to offer a cleaner substitute than this one ;-). In
particular I'm not happy with adding a sigsetjmp() cycle for every
single token parsed.
> It seems plainly hackish to mutate the body of yy_fatal_error() by #define'ing
> fprintf().
I agree, but the flex boys haven't provided any nicer API ...
at least not unless we'd like to convert to C++.
> Why didn't we instead #define YY_FATAL_ERROR and provide our own
> complete replacement?
For one reason, yy_fatal_error would still be there and would draw an
"unused static function" warning.
> On a related note, the out-of-memory handling during config file reload is
> inconsistent. guc-file.l uses palloc/pstrdup in various places. An OOM at
> those sites during a reload would kill the postmaster.
If you've got OOM in the postmaster, you're dead anyway. I feel no
compulsion to worry about this.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
