Re: Sort support for macaddr8

On Tue, Jun 4, 2019 at 3:50 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:

> On Tue, Jun 4, 2019 at 3:23 PM Andres Freund <andres(at)anarazel(dot)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.

--
Melanie Plageman