From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Richard Guo <guofenglinux(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Converting SetOp to read its two inputs separately |
Date: | 2024-12-19 22:23:06 |
Message-ID: | 538343.1734646986@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Pushed ... and now I have one more beef about the way things are
in this area. I don't think we should leave the compatibility
function BuildTupleHashTable() in place in HEAD. Making it a
wrapper around a new function BuildTupleHashTableExt() was a fine
solution for preserving ABI in released branches, but that doesn't
mean we should clutter the code with unused ABI hacks forevermore.
Attached is a patch to take it out and then rename
BuildTupleHashTableExt() back to BuildTupleHashTable().
Since BuildTupleHashTableExt has already grown more arguments
in HEAD than it had in v17, renaming it doesn't increase the number of
places that will have to be touched in any extensions that were using
this infrastructure. Removal of the compatibility wrapper could force
some code updates, but really we want those places to update anyway.
I also made an effort at fixing the woefully out of date
header comment for it.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Get-rid-of-old-version-of-BuildTupleHashTable.patch | text/x-diff | 15.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2024-12-19 22:29:12 | Re: AIO v2.0 |
Previous Message | Masahiko Sawada | 2024-12-19 22:05:30 | Re: Parallel heap vacuum |