Hi, On 2019-06-05 09:18:34 -0700, Melanie Plageman wrote: > On Tue, Jun 4, 2019 at 3:50 PM Peter Geoghegan <p...@bowt.ie> wrote: > > > On Tue, Jun 4, 2019 at 3:23 PM Andres Freund <and...@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.
I'd much rather see this tackled in a general way than fiddling with individual datatypes. I think we should: 1) make fetch_att(), store_att_byval() etc support datums of any length between 1 and <= sizeof(Datum). Probably also convert them to inline functions. There's a few more functions to be adjusted, but not many, I think. 2) Remove ability to pass PASSEDBYVALUE to CREATE TYPE, but instead compute whether attyval is possible, solely based on INTERNALLENGTH (when INTERNALLENGTH > 0 obviously). 3) Fix the fallout, by fixing a few of the Datum<->type conversion functions affected by this change. That'll require a bit of work, but not too much. We should write those conversion routines in a way that'll keep them working for the scenarios where the type is actually passable by value, and not (required for > 4 byte datums). Greetings, Andres Freund