Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error messages
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error messages |
Дата | |
Msg-id | 22061.951191794@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error messages (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error messages
Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error messages Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error messages |
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes: > On 2000-02-20, Tom Lane mentioned: >> I would not like us to stop working >> with non-bison yaccs, since bison's output depends on alloca() which >> is not available everywhere. > Couldn't alloca(x) be defined to palloc(x) where missing? Probably, but I wasn't looking for a workaround; that was just one quick illustration of a reason not to want to use bison (one that's bitten me personally, so I knew it offhand). We should try not to become dependent on bison when there are near-equivalent tools, just on general principles of maintaining portability. For an analogy, I believe most of the developers use gcc, but it would be a real bad idea for us to abandon support for other compilers. For the same sort of reasons I'd prefer that our scanner worked with vanilla lex, not just flex. I'm not sure how far away we are from that; it may be an unrealistic goal. But if it is within reach then we shouldn't give it up lightly. regards, tom lane
В списке pgsql-hackers по дате отправления: