On Thu, Jun 23, 2022 at 10:17 AM Andres Freund <and...@anarazel.de> wrote: > > This would require: > > > > - changing star expansion in SELECTs (expandRTE etc) > > - adjusting pg_dump, \d, etc > > > > That much seems clear and agreed upon. > > FWIW, I don't agree that this is a reasonable way to tackle changing > NAMEDATALEN. It'd be nice to have, but it to me it seems a pretty small > fraction of the problem of making Names variable length. You'll still have all > the problems of name fields being accessed all over, but now not being > included in the part of the struct visible to C etc.
Yeah, I agree. I think that being able to reorder columns logically without changing anything physically would be cool, but I think we could find some way of making the catalog columns variable-length without introducing that feature. I'm not sure whether your idea of creating translator functions is a good one or not, but it doesn't seem too crazy. It'd be like a special purpose tuple deformer. deform_pg_class_tuple(&pg_class_struct, pg_class_tuple); The code in there could be automatically generated statements that maybe look like this: memcpy(&struct.relnamespace, tuple + Aoffset_pg_class_relnamespace, sizeof(Oid)); Once you hit the first variable-length field you'd need something more clever, but because the code would be specialized for each catalog, it would probably be quite fast anyway. -- Robert Haas EDB: http://www.enterprisedb.com
