On Wed, Oct 2, 2019 at 12:03 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > I'm afraid that's going to be a deal-breaker for lots of people. > It's fine for prototyping the idea but we'll need to find another > implementation before we can move to commit.
Why do you think it will be a deal-breaker for lots of people? I mean, if we get this to a point where it just requires installing some reasonably modern version of LLVM, I don't see why that's worse than having to do the same thing for say, Perl if you want to build --with-perl, or Python if you want to build --with-python, or bison or lex if you want to change the lexer and parser. One more build-time dependency shouldn't be a big deal, as long as we don't need a really specific version. Or am I missing something? > > One concern I have is about whether the > > code that uses LLVM is likely to be dependent on specific LLVM > > versions. > > Yeah, that's one of the reasons it's a deal-breaker. We've been able to > insist that everybody touching configure use the same autoconf version, > but I don't think that could possibly fly for LLVM. But without that, > all the derived files would change in random ways depending on who'd > committed last. Even if it's only whitespace changes, that'd be a mess. I don't really see a reason why that would be an issue here. The code Andres wrote just uses LLVM to parse the structure definitions from our header files; the code generation stuff is hand-rolled and just prints out C. It's basically two big arrays, one of which is indexed by NodeTag and thus in a fixed order, and the other of which is an array of all structure members of all node types. The latter doesn't seem to be sorted in any terribly obvious way at the moment -- structure members are in order of occurrence within the corresponding definition, but the definitions themselves are not in any super-obvious order. That could presumably be fixed pretty easily, though. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
