Re: automatically generating node support functions

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: automatically generating node support functions
Date: 2021-06-08 17:45:58
Message-ID: a3020033-21a9-6ca6-251f-f95b03fbb978@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 08.06.21 15:40, David Rowley wrote:
> It's almost 2 years ago now, but I'm wondering if you saw what Andres
> proposed in [1]? The idea was basically to make a metadata array of
> the node structs so that, instead of having to output large amounts of
> .c code to do read/write/copy/equals, instead just have small
> functions that loop over the elements in the array for the given
> struct and perform the required operation based on the type.

That project was technologically impressive, but it seemed to have
significant hurdles to overcome before it can be useful. My proposal is
usable and useful today. And it doesn't prevent anyone from working on
a more sophisticated solution.

> There were still quite a lot of unsolved problems, for example, how to
> determine the length of arrays so that we know how many bytes to
> compare in equal funcs. I had a quick look at what you've got and
> see you've got a solution for that by looking at the last "int" field
> before the array and using that. (I wonder if you'd be better to use
> something more along the lines of your pg_node_attr() for that?)

I considered that, but since the convention seemed to work everywhere, I
left it. But it wouldn't be hard to change.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2021-06-08 18:01:51 Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
Previous Message Justin Pryzby 2021-06-08 17:34:04 Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic