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.
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 |