Re: Should we work around msvc failing to compile tab-complete.c?
От | Tom Lane |
---|---|
Тема | Re: Should we work around msvc failing to compile tab-complete.c? |
Дата | |
Msg-id | 1175213.1720462683@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Should we work around msvc failing to compile tab-complete.c? (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Should we work around msvc failing to compile tab-complete.c?
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.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
В списке pgsql-hackers по дате отправления: