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

On Fri, Aug 30, 2019 at 9:03 AM Fabien COELHO <coelho@cri.ensmp.fr> wrote:
> I have found this thread:
>
> https://www.postgresql.org/message-id/flat/E1cq93r-0004ey-Mp%40gemulon.postgresql.org
>
> It seems that comments from committers discouraged me to go on… :-) For
> instance Robert wanted a "checker", which is basically harder than a
> generator because you have to parse both sides and then compare.

Well, I don't think I intended to ask for something that was more
difficult than a full generator.  I think it's more that I had the
idea that a checker would be simpler.  It's true that you'd have to
parse both sides and compare. On the other hand, a checker can be
incomplete -- only checking certain things -- whereas a generator has
to work completely -- including all of the strange cases. So it seemed
to me that a checker would allow for tolerating more in the way of
exceptions than a generator. A generator also has to integrate
properly into the build system, which can be tricky.

It seems like the approach Andres is proposing here could work pretty
well. I think the biggest possible problem is that any semi-serious
developer will basically have to have LLVM installed. To build the
software, you wouldn't need LLVM unless you want to build with JIT
support. But to modify the software, you'll need LLVM for any
modification that touches node definitions. I don't know how much of a
nuisance that's likely to be for people, especially people developing
on less-mainstream platforms. One concern I have is about whether the
code that uses LLVM is likely to be dependent on specific LLVM
versions. If I can just type something like 'yum/port/brew/apt-get
install llvm' on any semi-modern platform and have that be good
enough, it won't bother me much at all.

On the other hand, if I have to hand-compile it because RHEL version
$X only ships older LLVM $Y (or ships unexpectedly-newer version $YY)
then that's going to be annoying. We already have the same annoyance
with autoconf; at some times, I've needed to have multiple versions
installed locally to cater to all the branches. However, that's less
of a problem than this would be, because (1) updating configure is a
substantially less-common need than updating node definitions and (2)
autoconf is a much smaller piece of software than libclang. It builds
in about 1 second, which I bet LLVM does not.

To point to an analogous case, note that we pretty much have to adjust
a bunch of things every few years to be able to support new versions
of Visual Studio, and until we do, it Just Doesn't Work. That stinks.
In contrast, new versions of gcc often cause new warnings, but those
are easier to work around until such time as somebody gets around to
cleaning them up. But most developers get to ignore Windows most of
the time, whereas if this breaks for somebody, they can't really work
at all until they either work around it on their side or it gets fixed
upstream.  So it's a significant potential inconvenience.

As a benchmark, I'd propose this: if the LLVM interfaces that this new
code would use work in all versions of LLVM released in the last 3
years and there's no indication that they will change in the next
release, then I'd feel pretty comfortable. If they've changed once,
that'd probably still be OK.  If they've changed more than once,
perhaps we should think about a Perl script under our own control as
an alternative, so as to avoid having to keep adjusting the C code
every time LLVM whacks the interfaces around.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company