public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andres Freund <[email protected]>
To: Tom Lane <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: David Rowley <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: automatically generating node support functions
Date: Wed, 14 Jul 2021 18:24:54 -0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<CAApHDvogX3_F9CZrb4KpquPeYzyv7Z=v31EA1T5L6Lq+n12bRg@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>

Hi,

On 2021-07-14 17:42:10 -0400, Tom Lane wrote:
> I think the main reason that the previous patch went nowhere was general
> resistance to making developers install something as complicated as
> libclang --- that could be a big lift on non-mainstream platforms.

I'm still not particularly convinced it's and issue - I was suggesting
we commit the resulting metadata, so libclang would only be needed when
modifying node types. And even in case one needs to desperately modify
node types on a system without access to libclang, for an occasionally
small change one could just modify the committed metadata structs
manually.


> So IMO it's a feature not a bug that Peter's approach just uses a perl
> script.  OTOH, the downstream aspects of your patch did seem appealing.
> So I'd like to see a merger of the two approaches, using perl for the
> data extraction and then something like what you'd done.  Maybe that's
> the same thing you're saying.

Yes, that's what I was trying to say. I'm still doubtful it's a great
idea to go further down the "weird subset of C parsed by regexes" road,
but I can live with it.  If Peter could generate something roughly like
the metadata I emitted, I'd rebase my node functions ontop of that.


> I also see Peter's point that committing what he has here might be
> a reasonable first step on that road.  Getting the data extraction
> right is a big chunk of the job, and what we do with it afterward
> could be improved later.

To me that seems likely to just cause churn without saving much
effort. The needed information isn't really the same between generating
the node functions as text and collecting the metadata for "generic node
functions", and none of the output is the same.

Greetings,

Andres Freund

view thread (77+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: automatically generating node support functions
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox