From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Should we work around msvc failing to compile tab-complete.c? |
Date: | 2024-07-08 17:48:04 |
Message-ID: | 20240708174804.pfrnxtzusudznhfd@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Compiling postgres on windows with tab-completion support fails either with
"fatal error C1026: parser stack overflow, program too complex”.
or (in recent versions) with
"…/src/bin/psql/tab-complete.c(4023): fatal error C1001: Internal compiler error."
I've reported this to the visual studio folks at [1] and supposedly a fix is
waiting to be released. I don't know if that's just for the internal compiler
error in 2022 or lifting the limitation.
It's pretty easy to work around the error [2]. I wonder if we should just do
that, then we don't have to insist on a very new msvc version being used and
it'll work even if they just decide to fix the internal compiler error.
Besides just breaking the if-else-if chain at some arbitrary point, we could
alternatively make a more general efficiency improvement, and add a bit of
nesting at a few places. E.g. instead of having ~33 checks for COMMENT being
the first word, we could use "outer" else-if for COMMENT and check the
sub-variants inside that branch:
else if (HeadMatches("COMMENT"))
{
if (Matches("COMMENT"))
COMPLETE_WITH("ON");
else if (Matches("COMMENT", "ON"))
...
}
if we do that to one or two common keywords (COMMENT and DROP seems easiest)
we'd be out from that limitation, and would probably reduce the number of
cycles for completions noticeably.
OTOH, that'd be a more noisy change and it'd be less defensible to apply it to
17 - which IMO would be nice to do.
Greetings,
Andres Freund
[1] https://developercommunity.visualstudio.com/t/tab-completec4023:-fatal-error-C1001:/10685868
[2] https://postgr.es/m/CACLU5mRRLAW2kca3k2gVDM8kow6wgvT_BCaeg37jz%3DKyj1afvw%40mail.gmail.com
From | Date | Subject | |
---|---|---|---|
Next Message | MARK CALLAGHAN | 2024-07-08 17:49:31 | Re: debugging what might be a perf regression in 17beta2 |
Previous Message | David E. Wheeler | 2024-07-08 17:34:45 | Re: jsonpath: Inconsistency of timestamp_tz() Output |