Re: reducing the footprint of ScanKeyword (was Re: Large writablevariables)
От | Andres Freund |
---|---|
Тема | Re: reducing the footprint of ScanKeyword (was Re: Large writablevariables) |
Дата | |
Msg-id | 20190104223615.zz2xkwbseoeuzg6c@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: reducing the footprint of ScanKeyword (was Re: Large writable variables) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: reducing the footprint of ScanKeyword (was Re: Large writablevariables)
|
Список | pgsql-hackers |
Hi, On 2019-01-04 16:43:39 -0500, Tom Lane wrote: > Joerg Sonnenberger <joerg@bec.de> writes: > >> * What's the generator written in? (if the answer's not "Perl", wedging > >> it into our build processes might be painful) > > > Plain C, nothing really fancy in it. > > That's actually a bigger problem than you might think, because it > doesn't fit in very nicely in a cross-compiling build: we might not > have any C compiler at hand that generates programs that can execute > on the build machine. That's why we prefer Perl for tools that need > to execute during the build. However, if the code is pretty small > and fast, maybe translating it to Perl is feasible. Or perhaps > we could add sufficient autoconfiscation infrastructure to identify > a native C compiler. It's not very likely that there isn't one, > but it is possible that nothing we learned about the configured > target compiler would apply to it :-( I think it might be ok if we included the output of the generator in the buildtree? Not being able to add keywords while cross-compiling sounds like an acceptable restriction to me. I assume we'd likely grow further users of such a generator over time, and some of the input lists might be big enough that we'd not want to force it to be recomputed on every machine. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: