On Fri, Jun 9, 2023 at 12:03 PM Andres Freund <and...@anarazel.de> wrote: > From what I can tell it's largely consistent with other parameters of the > respective function. E.g. btinsert(), _bt_doinsert() use camelCase for most > parameters, so heapRel fits in. There are a few cases where it's not obvious > what the pattern is intended to be :/.
It's not 100% clear what the underlying principle is, but we mix camelCase and underscore styles all the time, so that's always kinda true. > > My new plan is to commit this tomorrow, since the clear consensus is > > that we should go ahead with this for 16. > > I'm not sure there is that concensus (for me half the changes shouldn't be > done, the rest should be in 17), but in the end it doesn't matter that much. Really? What parts are you opposed to in principle? I don't see why you wouldn't support everything or nothing for 17 (questions of style aside). I don't see what's ambiguous about what we should do here, barring the 16-or-17 question. It's not like nbtree ever really "used P_NEW". It doesn't actually depend on any of the P_NEW handling inside bufmgr.c. It looks a little like it might, but that's just an accident. > > --- a/src/include/utils/tuplesort.h > > +++ b/src/include/utils/tuplesort.h > > @@ -399,9 +399,7 @@ extern Tuplesortstate *tuplesort_begin_heap(TupleDesc > > tupDesc, > > > > int workMem, SortCoordinate coordinate, > > > > int sortopt); > > extern Tuplesortstate *tuplesort_begin_cluster(TupleDesc tupDesc, > > - > > Relation indexRel, > > - > > Relation heaprel, > > - > > int workMem, > > + > > Relation indexRel, int workMem, > > > > SortCoordinate coordinate, > > > > int sortopt); > > I think we should continue to provide the table here, even if we don't need it > today. I don't see why, but okay. I'll do it that way. -- Peter Geoghegan
