From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: Generic functions for Node types using generated metadata |
Date: | 2019-10-02 18:47:22 |
Message-ID: | 15545.1570042042@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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?
Think it's available/trivially installable on e.g. Windows? I'm not
convinced. In any case, our list of build requirements is depressingly
long already.
The existing expectation is that we make our build tools in Perl.
I'm sure Andres doesn't want to write a C parser in Perl, but
poking around suggests that there are multiple options already
available in CPAN. I'd much rather tell people "oh, there's YA
module you need to get from CPAN" than "figure out how to install
version XXX of LLVM".
The other direction we could plausibly go in is to give up the
assuption that parsenodes.h and friends are the authoritative
source of info, and instead declare all these structs in a little
language based on JSON or what-have-you, from which we generate
parsenodes.h along with the backend/nodes/ files. I kind of
suspect that we'll be forced into that eventually anyway, because
one thing you are not going to get from LLVM or a pre-existing
Perl C parser is anything but the lowest-common-denominator version
of what's in the structs. I find it really hard to believe that
we won't need some semantic annotations in addition to the bare C
struct declarations. As an example: in some cases, pointer values
in a Node struct point to arrays of length determined by a different
field in the struct. How do we tie those together without magic?
I think there has to be an annotation marking the connection, and
we're not going to find that out from LLVM.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2019-10-02 18:52:31 | Re: Collation versioning |
Previous Message | Mark Dilger | 2019-10-02 18:39:22 | Re: Proposal: Make use of C99 designated initialisers for nulls/values arrays |