From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Should we work around msvc failing to compile tab-complete.c? |
Date: | 2024-07-08 18:18:03 |
Message-ID: | 1175213.1720462683@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> 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."
> 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.
I'm on board with doing something here, but wouldn't we want to
back-patch at least a minimal fix to all supported branches?
As for the specific thing to do, that long if-chain seems horrid
from an efficiency standpoint as well as stressing compiler
implementations. I realize that this pretty much only needs to run
at human-reaction-time speed, but it still offends my inner nerd.
I also wonder when we are going to hit problems with some earlier
test unexpectedly pre-empting some later one.
Could we perhaps have a table of first words of each interesting
match, and do a lookup in that before dispatching to code segments
that are individually similar to what's there now?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Melanie Plageman | 2024-07-08 18:25:16 | Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin |
Previous Message | Melanie Plageman | 2024-07-08 18:16:13 | Re: Confine vacuum skip logic to lazy_scan_skip |