Re: WIP: Generic functions for Node types using generated metadata

On Wed, Oct 2, 2019 at 12:03 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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