On Tue, Jun 4, 2019 at 3:50 PM Peter Geoghegan <pg@bowt.ie> wrote:
On Tue, Jun 4, 2019 at 3:23 PM Andres Freund <andres@anarazel.de> wrote: > > This is half the reason why I ended up implementing itemptr_encode() > > to accelerate the TID sort used by CREATE INDEX CONCURRENTLY some > > years back -- TID is 6 bytes wide, which doesn't have the necessary > > macro support within postgres.h. There is no reason why that couldn't > > be added for the benefit of both TID and macaddr types, though it > > probably wouldn't be worth it. > > I think we should definitely do that. It seems not unlikely that other > people want to write new fixed width types, and we shouldn't have them > deal with all this complexity unnecessarily.
On second thought, maybe there is something to be said for being exhaustive here.
It seems like there is a preference for making macaddr8 pass-by-value instead of adding abbreviated keys support to macaddr8, and possibly doing the same with the original macaddr type.
Do you think that you'll be able to work on the project with this expanded scope, Melanie?
I can take on making macaddr8 pass-by-value I tinkered a bit last night and got in/out mostly working (I think). I'm not sure about macaddr, TID, and user-defined types.
